Développement spécifique sous Odoo
Un développement sur mesure n'est pas un coût unique. C'est un engagement que vous reprendrez à chaque nouvelle version. Voici comment nous le traitons.
Nous préférons coder un module que paramétrer sans code
Odoo propose un outil de personnalisation sans développeur, présenté comme la solution rapide et économique. Nous ne l'utilisons pas pour les besoins structurants, et nous assumons d'aller à contre-courant sur ce point.
La raison tient en un mot : la migration. Un module développé proprement se relit, se teste et se reprend à chaque montée de version. Un empilement de personnalisations faites dans l'interface se documente mal, se relit difficilement, et se retrouve à devoir être reconstitué au moment le plus contraint du cycle de vie de votre ERP.
Coder coûte un peu plus cher au départ. Cela coûte nettement moins cher la troisième année.
Un développement non documenté est une dette, pas un actif
Le moment le plus dur de l'un de nos projets clients (La clé rapide) n'a pas été technique. Il a été archéologique.
L'entreprise avait hérité de développements réalisés par une équipe précédente, dont une gestion spécifique du calcul des tarifs par client. Plus personne dans la société ne savait dire ce que ce système faisait, ni pourquoi il avait été construit ainsi. Il a fallu comprendre avant de pouvoir remplacer.
C'est le scénario que nous cherchons à éviter chez nos clients. Un module livré sans explication de la règle métier qu'il porte devient une boîte noire le jour où la personne qui l'a demandé quitte l'entreprise. Nous écrivons ce que fait le module, pas seulement son code.
Le vrai coût se paie à la version suivante
Odoo publie une version majeure par an. Chaque développement spécifique doit être vérifié, parfois adapté. Cela vaut aussi pour les modules payants du marché, et c'est le point le moins souvent annoncé en avant-vente.
Sur le projet Incept Sport, les modules transporteurs disponibles se repayaient à chaque montée de version. Nous avons choisi avec le client d'attendre la sortie d'une version majeure qui couvrait le besoin, plutôt que d'acheter deux fois. Le projet a été décalé, et c'était la bonne décision économique.
Chez L'Addition, éditeur de logiciel d'encaissement, la difficulté est venue d'ailleurs : des échanges de fichiers automatisés avec des partenaires bancaires et logistiques, dont les librairies n'étaient plus compatibles avec la version cible. Le spécifique n'avait pas cassé à cause d'Odoo, mais à cause des solutions tierces.
Module du marché ou développement propre
Un module existant coûte moins cher tout de suite. Il vous lie en revanche au rythme de son éditeur, à sa politique de prix et à sa capacité à suivre les versions d'Odoo.
Nous regardons trois choses avant de trancher : depuis combien de temps le module est maintenu, ce qu'il coûte réellement sur trois ans en comptant les montées de version, et ce qui se passe si son auteur arrête. Quand la réponse à la troisième question est inconfortable, nous développons.
Ce que nous ne développons pas
Une bonne partie des demandes de spécifique disparaît après une heure de discussion. Ce sont des fonctions qui existent déjà en standard, demandées parce que l'ancien outil les présentait autrement.
Le réflexe le plus coûteux d'un projet ERP consiste à reproduire dans le nouveau système ce que faisait le précédent, y compris ce qui ne servait plus depuis des années. Nous posons systématiquement la question : qui utilise cette fonction aujourd'hui, et à quelle fréquence ?
Un développement en moins, c'est un poste en moins à reprendre à chaque version.
Ce qu'on ajoute à un site Odoo, au delà de la gestion
Un site Odoo n'est pas qu'une vitrine posée devant votre ERP. Comme il partage ses données, il peut porter des outils qui travaillent pour vous pendant que vous faites autre chose.
Un simulateur d'estimation, par exemple. Le nôtre tourne sur ce site : le visiteur coche son périmètre, obtient un ordre de grandeur, et une piste arrive directement dans le CRM avec ce qu'il a saisi. Pas un formulaire qui envoie un message, une piste qualifiée qui entre dans votre cycle commercial.
La différence avec un outil externe est structurelle. Un widget acheté sur étagère garde les réponses de vos visiteurs chez son éditeur et ne crée rien chez vous. Développé nativement, le même outil alimente votre base et se mesure.
Dans le même esprit : une prise de contact par messagerie instantanée pour les visiteurs qui ne rempliront jamais un formulaire, une prise de rendez-vous reliée aux agendas de vos équipes, un espace client qui donne accès aux commandes et aux documents sans passer par vous.
L'intelligence artificielle dans votre site et dans votre gestion
Nous nous sommes formés à l'intégration de l'IA dans les environnements Odoo, et nous le faisons entrer par le site plutôt que par des promesses générales.
Les cas qui ont du sens aujourd'hui sont concrets. Un assistant qui répond aux questions de vos visiteurs à partir de votre propre catalogue et de votre documentation, pas d'un modèle générique qui invente. Une qualification de demande entrante qui prépare le travail de vos commerciaux au lieu de le remplacer. La rédaction assistée de fiches produits à partir de vos données techniques, relue par vos équipes.
Ce que nous ne ferons pas : brancher un agent conversationnel sur votre site sans lui donner vos données, ou automatiser une réponse client sans que quelqu'un chez vous puisse la relire. Un outil qui se trompe devant un client coûte plus cher que le temps qu'il fait gagner.
Si le sujet vous intéresse, parlons de ce que vous voulez en faire avant de parler de technologie.
Ce que ça représente
Le développement spécifique ne figure pas dans notre grille d'estimation par application : il se chiffre à part, au temps passé.
Le simulateur vous donne l'ordre de grandeur de votre socle standard. Le spécifique s'ajoute ensuite, une fois le besoin réel identifié, et jamais avant de l'avoir compris.
Questions fréquentes
Un module développé pour nous nous appartient-il ?
Le code développé pour votre projet vous est livré. La question à poser à tout prestataire, nous compris, est de savoir ce que vous récupérez si vous changez d'intégrateur, et sous quelle forme.
Que devient notre spécifique à la prochaine version majeure ?
Il est vérifié et adapté. C'est un poste de la maintenance, pas une surprise. Une montée de version récente nous a demandé quinze heures hors personnalisations, et c'est précisément ce qualificatif qui fait la différence de budget d'un parc à l'autre.
Peut-on reprendre des développements faits par quelqu'un d'autre ?
Oui, et nous le faisons régulièrement. Le préalable est de comprendre ce que fait le code existant, ce qui prend du temps quand rien n'a été documenté. Nous chiffrons cette phase d'analyse séparément, pour que vous sachiez ce que vous payez.
Comment choisissez-vous entre paramétrage et développement ?
Par la durée de vie du besoin. Un ajustement d'affichage se paramètre. Une règle métier qui commande votre facturation se code, se teste et s'écrit.
Parlons de votre besoin
Estimez votre socle en quelques questions, le spécifique se chiffre ensuite sur mesure.
Un projet comparable ?
Estimez votre budget en quelques questions, ou regardez nos huit derniers projets.
Besoin de libérer et soutenir votre croissance ?
Dites-nous d'où vous partez. On vous répond avec un premier avis sur la faisabilité, le périmètre et l'ordre de grandeur, pas avec une plaquette.