En bref ANOR a choisi de ne pas porter son module « Achat rattaché à l'affaire » vers les versions récentes d'Odoo, car la fonctionnalité native couvre désormais ce besoin sans développement additionnel. Maintenir un module devenu superflu représente un coût réel, toujours répercuté sur le client. Supprimer ce qui ne sert plus est une décision de qualité, pas un aveu de faiblesse.
Un chantier, un achat et un rattachement qui s'oublie
Imaginez un chef de chantier qui commande des fournitures en urgence. Il saisit la commande fournisseur, fixe la quantité, valide. L'affaire concernée ? Il l'ajoutera plus tard. Souvent, « plus tard » n'arrive jamais.
Résultat : la dépense existe dans Odoo, mais elle flotte sans affectation. La marge du chantier affichée en fin de mois est fausse. Et l'erreur ne se voit qu'à la clôture, quand il est trop tard pour en tirer une leçon opérationnelle.
C'est exactement ce problème que notre module « Achat rattaché à l'affaire » résolvait. Il permettait de créer une commande d'achat directement depuis le projet, déjà liée à son affaire, sans aucune saisie manuelle. Le risque d'oubli disparaissait. La lecture de la rentabilité devenait fiable. Ce module a rendu de réels services.
Pourquoi nous avons décidé de ne pas le porter
À chaque nouvelle version d'Odoo, nous reprenons nos modules un par un. La question posée est toujours la même : ce module mérite-t-il encore d'exister dans cette version ?
Pour « Achat rattaché à l'affaire », la réponse était négative. Odoo avait évolué. La fonctionnalité native couvre désormais ce besoin de façon satisfaisante, sans développement additionnel. Le module que nous avons choisi de ne pas porter n'est donc pas un module défaillant : c'est un module devenu superflu.
Conserver un module inutile a un coût réel. Il faut le vérifier à chaque mise à jour, l'expliquer à chaque nouveau consultant et, surtout, le maintenir. Ce travail finit toujours par être payé par le client. Nous préférons retirer ce qui ne sert plus plutôt que le conserver par habitude.
Cinq principes qui guident chaque développement
Cette décision illustre la façon dont nous abordons tous nos projets. Cinq principes s'appliquent systématiquement.
- Le métier avant l'outil. Nous cherchons d'abord à comprendre le besoin réel de l'entreprise. Un module n'a de valeur que s'il comble un véritable manque.
- Une consigne écrite avant toute construction. Chaque développement spécifique part d'un cahier des charges précis, relu et validé avec le client. Il décrit le besoin en langage clair et précise ce qui ne doit pas être fait.
- Le cœur d'Odoo reste intact. Tout ajout se greffe par-dessus le logiciel et demeure réversible. Nos clients peuvent mettre à jour Odoo sans appréhension et nous quitter le jour où ils le souhaitent, sans être enfermés par un développement.
- L'étude avant l'écriture. Nous commençons toujours par comprendre comment Odoo fonctionne dans la version du client. Il nous est arrivé d'abandonner un développement bien avancé parce qu'un simple réglage suffisait. Le meilleur module est parfois un réglage bien posé.
- Le retrait de ce qui ne sert plus. Un module n'est pas un patrimoine à préserver. C'est une réponse apportée à un besoin. Quand le besoin disparaît, la réponse doit disparaître avec lui.
Ce que cela change concrètement pour vous
Si vous utilisez ce module sur une version antérieure d'Odoo, il continue de fonctionner normalement. Odoo 18 reste supportée par l'éditeur et nos équipes assurent le support et la maintenance sur les versions en cours de support.
Au moment de votre passage à Odoo 18, 19 ou 20, votre chef de projet fera le point avec vous. Il vous proposera la solution la plus simple pour répondre à votre besoin et ce n'est pas toujours un développement.
De manière plus générale, lorsque nous vous conseillons de ne pas développer quelque chose, c'est que le besoin ne le justifie pas. Un intégrateur qui vendrait du développement à tout prix ne servirait pas les intérêts de son client.
Ce que la sobriété d'un ERP dit de celui qui l'intègre
Pensez à la cuisine d'un restaurant. Ce qu'on voit en salle, c'est le résultat. Ce qu'on ne voit pas, c'est le choix de ne pas mettre un plat à la carte parce qu'il ne serait pas à la hauteur ce soir-là. La sobriété est un acte de qualité, pas une limitation.
Notre ambition est de remplacer les logiciels de gestion des PME françaises par un Odoo bien fichu. Un Odoo bien fichu est un Odoo sobre, dans lequel chaque ajout possède sa raison d'être. Nous publions nos modules quand ils apportent une vraie valeur. Nous vous disons franchement quand il vaut mieux ne rien publier du tout.
Si vous vous posez des questions sur vos propres développements, sur ce qu'il vaut mieux conserver, récrire ou simplement supprimer avant une migration Odoo, échangez avec l'un de nos consultants. Trente minutes suffisent souvent pour y voir clair.
Réserver 30 minutes avec un consultant
Questions fréquentes
Mon module « Achat rattaché à l'affaire » va-t-il continuer à fonctionner ?
Oui, sur votre version actuelle d'Odoo, il continue de fonctionner normalement. Au moment de votre migration, votre chef de projet fera le point avec vous et identifiera la solution la plus simple, qui n'est pas nécessairement un développement.
Pourquoi ANOR a-t-il décidé de ne pas porter ce module vers Odoo 18 ?
Odoo a évolué et couvre désormais ce besoin en natif. Conserver un module superflu génère des coûts de maintenance et de vérification à chaque mise à jour, que le client finit par payer. Nous avons préféré le retirer.
Comment ANOR décide-t-il qu'un développement est nécessaire ou non ?
Nous étudions d'abord comment Odoo fonctionne dans la version du client. Si un réglage natif suffit, nous n'écrivons aucun code. Un développement n'est engagé que si le besoin réel ne peut pas être couvert autrement.
Si ANOR me déconseille un développement, est-ce que cela signifie que mon besoin n'est pas légitime ?
Non. Cela signifie que le besoin peut être couvert d'une façon plus simple, plus pérenne et moins coûteuse. Le conseil en organisation fait partie de notre approche, indépendamment de tout développement.
Qu'arrive-t-il à mes développements spécifiques si je quitte ANOR ?
Le code vous appartient. Nos développements se greffent par-dessus Odoo et restent réversibles. Vous pouvez migrer, changer d'intégrateur ou mettre à jour Odoo sans être enfermé par un développement qui vous dépasse.