Un audit, chez Ekonum, n’est pas un diagnostic fonctionnel ni un simple relevé de besoins.
C’est un raisonnement structuré, qui cherche à répondre à une question fondamentale :
Quelle fonctionnalité faut-il mettre en place, à quel moment, et à quel coût ?
Pour y répondre, nous devons reconstituer le fil logique qui relie la réalité d’une entreprise à sa traduction dans un système d’information.
Autrement dit : comprendre avant de modéliser, modéliser avant de chiffrer, chiffrer avant de planifier.
Notre méthodologie d’audit repose donc sur une progression en cinq étapes :
L’analyse du besoin fonctionnel, où l’on cartographie les flux qui composent l’entreprise pour en comprendre le fonctionnement global.
L’analyse des écarts, qui confronte ces flux à la structure d’Odoo et identifie les adaptations nécessaires.
Les spécifications techniques, qui traduisent la complexité en éléments mesurables, sans encore tomber dans la logique du code.
Le chiffrage, qui évalue la faisabilité et la rentabilité des fonctionnalités, en assumant la part d’intuition inhérente à toute planification humaine.
L’analyse du retour sur investissement, qui transforme cette réflexion en outil de décision économique.
Chaque étape répond à une seule exigence : ne jamais simplifier un raisonnement complexe, mais l’expliquer.
La simplification est un confort pour le lecteur, pas pour la vérité.
Notre rôle, dans un audit, est d’être précis, cohérent et honnête — même si cela prend du temps, même si cela décourage les pressés.
1. Analyse du besoin fonctionnel : comprendre avant de cartographier
Avant d’intégrer quoi que ce soit, il faut comprendre à quoi sert l’entreprise, comment elle fonctionne, et surtout, comment ses flux s’enchaînent. Une entreprise n’est pas une somme de logiciels ni même de départements ; c’est un système vivant, où chaque flux produit ou consomme de la valeur.
Notre premier réflexe consiste donc à décrire ces flux : quand commence réellement l’activité ? Que se passe-t-il entre le premier contact et la dernière facture ? Où la valeur se crée-t-elle, où se perd-elle ?
Ce travail repose sur une catégorisation qui se veut exhaustive, applicable à n’importe quelle structure — qu’il s’agisse d’un cabinet comptable, d’un viticulteur ou d’une startup technologique.
1. Le pilotage stratégique
C’est le cœur rationnel de l’entreprise. Il définit la mission, les objectifs et la trajectoire : à quoi sert cette organisation, et comment saura-t-on qu’elle avance ?
On y retrouve la direction, la planification, la mesure de la performance, la gestion des risques et la gouvernance. En résumé, c’est le flux de la décision : celui qui trace la route avant que quiconque ne commence à marcher.
2. L’acquisition
C’est le flux d’entrée. Comment attire-t-on des clients, partenaires, membres ou bénéficiaires ? Par quels canaux ?
Inbound (communication, réputation, référencement, bouche-à-oreille) ou outbound (prospection, appels, relances) : peu importe le moyen, l’objectif reste de transformer un inconnu en opportunité. Ce flux dicte tout le reste : si l’entrée de valeur est mauvaise, aucune optimisation interne ne compensera la fuite.
3. La production ou livraison
C’est ici que la promesse faite au client devient réelle.
Production, logistique, gestion de projet, prestation de service, approvisionnement ou fabrication : chaque activité transforme une ressource en résultat tangible. Ce flux représente la création de valeur. Il concentre souvent la plus grande complexité, car il combine contraintes humaines, matérielles et temporelles.
4. Le support opérationnel
Tout ce qui ne produit rien directement mais sans quoi rien ne se produirait.
Ressources humaines, parc matériel, infrastructures, systèmes d’information, juridique, sécurité, documentation : ce sont les muscles et les os de l’entreprise. Ce flux, souvent invisible, est pourtant celui qui garantit la stabilité du reste.
5. La finance et l’administration
Ce flux mesure, contrôle et relie.
Comptabilité, facturation, trésorerie, fiscalité, contrôle de gestion : c’est la traduction chiffrée du réel. La finance n’est pas qu’un exercice comptable ; elle raconte comment les décisions et les opérations se transforment en argent. C’est le flux de la mesure de la valeur, celui qui permet de distinguer la performance de l’impression de performance.
6. L’amélioration continue et la conformité
Dernier flux, souvent négligé : celui du retour d’expérience.
Audit, qualité, sécurité, innovation, durabilité, documentation — tout ce qui transforme les erreurs d’hier en bonnes pratiques de demain. C’est la boucle de rétroaction qui ferme le cycle et permet à l’entreprise de se réinventer sans se perdre.
En cartographiant une entreprise selon ces six flux, on obtient un modèle complet : un système où chaque flux alimente le suivant. Le pilotage fixe la direction, l’acquisition crée les opportunités, la production délivre, le support maintient, la finance évalue, et l’amélioration ajuste.
Ce schéma est notre point de départ : sans lui, l’audit n’a pas de terrain d’analyse, et tout projet de transformation devient un simple exercice d’opinion.
2. Analyse des écarts : confronter la théorie au réel
Une fois les flux métiers compris et représentés, il faut les confronter à la réalité technique. C’est ici que commence le travail d’audit à proprement parler : traduire les processus d’entreprise en fonctionnalités concrètes dans Odoo, et mesurer les écarts entre ce que l’entreprise fait et ce que le logiciel sait faire.
Odoo est une boîte à outils complète, mais pas magique. Il dispose d’un socle fonctionnel très large — ventes, achats, projets, RH, comptabilité, site web, etc. —, et d’une architecture modulaire qui lui permet de s’adapter presque à tout. L’enjeu n’est donc pas de “faire rentrer” le client dans Odoo, mais de comprendre comment Odoo peut épouser ses flux sans les dénaturer.
Pour cela, nous traduisons les diagrammes de flux établis lors de l’analyse fonctionnelle en cartographie des fonctionnalités : chaque étape d’un processus est associée à une fonctionnalité standard ou à une adaptation possible.
Cette analyse suit une grille de lecture à quatre niveaux, qui permet de situer chaque besoin sur une échelle de complexité croissante :
Niveau 1 — Fonctionnalité disponible en standard
Le besoin est couvert nativement par Odoo. Il suffit de la paramétrer correctement. Exemple : gérer des devis, suivre des factures, définir des règles de stock, planifier des projets. Rien à développer, tout est prévu — encore faut-il savoir que ça existe.
Niveau 2 — Fonctionnalité standard nécessitant une expertise approfondie
Le besoin est couvert par Odoo, mais sa mise en œuvre suppose une maîtrise fine du logiciel ou une connaissance métier spécifique.
Exemple : les routes logistiques complexes, la construction d'un rapport comptable, la configuration d’un plan comptable multi-sociétés, ou les règles de paie.
Ici, la difficulté ne réside pas dans Odoo lui-même, mais dans la compréhension du contexte. On touche à la zone grise entre paramétrage et ingénierie fonctionnelle.
Niveau 3 — Personnalisation via Odoo Studio (no-code)
Le besoin n’est pas couvert directement, mais peut être satisfait sans écrire de code, grâce à Odoo Studio, le moteur d’édition intégré.
On y ajoute un champ, on crée une automatisation simple, on récupère une donnée via une action serveur ou une API basique. C’est rapide, efficace et réversible.
Ce niveau suppose de bien maîtriser les limites du no-code : l’outil est puissant tant qu’il reste simple. Dès qu’on cherche à reproduire un comportement dynamique complexe, le Studio devient une impasse élégante.
Niveau 4 — Développement d’un module personnalisé
Le besoin sort du périmètre d’Odoo standard et requiert du code.
On développe alors un module spécifique, installé sur Odoo SH ou On-Premise. Cela suppose d’écrire des modèles, des vues, et des contrôleurs (l’architecture MVC sur laquelle repose Odoo).
Chaque module développé devient une pièce du système à maintenir, documenter, tester et versionner. Ce niveau doit donc être réservé à ce qui a une véritable valeur stratégique pour le client.
Cette grille permet d’évaluer objectivement la distance entre le besoin métier et les capacités du standard. Elle transforme un discours flou (“on va devoir personnaliser”) en une mesure concrète : combien de besoins sont de niveau 1, 2, 3 ou 4 ?
En d’autres termes, elle convertit le ressenti en structure, et la complexité en chiffrage.
Une entreprise dont 80 % des besoins se situent au niveau 1 ou 2 n’a pas un projet lourd : elle a un projet mal compris. À l’inverse, si la majorité des flux tombent au niveau 3 ou 4, ce n’est pas une faiblesse d’Odoo, mais le signe qu’il faut repenser certains processus métiers avant de les automatiser.
L’analyse des écarts n’a donc pas pour objectif de “faire rentrer” le besoin dans le logiciel, mais de mesurer à quel point le logiciel et l’entreprise parlent le même langage — et combien de mots il va falloir inventer pour qu’ils se comprennent.
3. Spécifications techniques : traduire la complexité sans la travestir
Une fois les écarts identifiés, vient l’étape la plus souvent négligée : celle des spécifications. C’est pourtant ici que se joue la différence entre un projet maîtrisé et un projet hasardeux.
Le but d’une spécification n’est pas d’écrire du code sur le papier, mais de quantifier la complexité, d’estimer le périmètre, et de rendre le travail chiffrable sans exiger encore de le réaliser.
Chez Ekonum, les spécifications techniques ne sont pas de simples annexes. Elles forment la charpente du chiffrage et du plan de développement.
1. Cas du no-code : Odoo Studio
Lorsqu’une fonctionnalité peut être réalisée avec Odoo Studio, la spécification se limite à décrire la logique fonctionnelle :
quand l’automatisation se déclenche, quelle valeur elle calcule, où elle s’applique, et quelle donnée elle manipule.
Tout doit rester simple : ajout d’un champ, calcul automatique, action serveur, récupération d’une donnée via une API standard.
Au-delà, le no-code devient un nid à dettes techniques déguisées en simplicité. La règle est donc claire : dès qu’une automatisation demande plus d’une phrase pour être expliquée, on sort du périmètre du Studio.
2. Cas du développement : Odoo SH
Lorsqu’une fonctionnalité nécessite un module spécifique, on rédige une spécification technique détaillée, mais sans tomber dans le piège du « code par anticipation ».
Le but n’est pas de définir comment tout sera développé, mais combien de briques seront nécessaires.
Odoo repose sur une architecture MVC (Modèle, Vue, Contrôleur) :
Modèle : la structure de la donnée en base et les relations entre objets. Exemple : un devis, un contact, un utilisateur, un entrepôt.
Vue : la manière dont cette donnée est affichée au client, rendue via QWeb ou OWL.
Contrôleur : la logique de transit entre le serveur et le navigateur, y compris la gestion des accès et des requêtes.
La spécification technique vise à estimer le volume de ces éléments par fonctionnalité : combien de modèles, combien de vues, combien de contrôleurs ?
Cette approche ne cherche pas l’exactitude (qui serait illusoire avant le développement) mais un ordre de grandeur stable.
C’est sur cette base que nous chiffrons les développements. Nous y ajoutons :
le nombre d’intégrations externes à réaliser et leur complexité ;
le volume de tests (automatisés et humains) à prévoir ;
la documentation associée à produire ;
la maintenance future induite par ces choix.
Bien sûr, c’est une IA qui fait le gros du travail : on lui fait rédiger les spécifications et le chiffrage à partir de l'analyse fonctionnelle en la contraignant à respecter cette grille, ce qui le rend particulièrement précise.
En d’autres termes, une bonne spécification ne dit pas “ce qu’on veut faire”, mais jusqu’où on est prêt à aller pour le faire.
Elle est un outil de cadrage, pas une notice technique.
Elle transforme la complexité en métrique, et la créativité du développeur en paramètre mesurable.
4. Chiffrage : entre mesure, intuition et honnêteté intellectuelle
Le chiffrage est la frontière entre la théorie et la réalité. C’est là qu’on quitte la pure logique pour affronter l’incertitude.
Son rôle n’est pas de prédire un coût exact, mais de répondre à une question plus simple et plus honnête : est-ce que cette fonctionnalité mérite d’exister ?
Un bon audit ne cherche pas la précision arithmétique, mais la cohérence intellectuelle. Il s’agit de savoir si le développement envisagé est économiquement rationnel, et à quel point il s’inscrit dans la logique globale du système Odoo.
1. Regrouper les spécifications en modules cohérents
Une fois les besoins identifiés et décrits, nous les regroupons par ensemble fonctionnel : les modules.
Chaque module doit pouvoir exister indépendamment, c’est-à-dire être commercialisable au sens conceptuel du terme — un module qu’on pourrait, en théorie, proposer à la communauté.
Cette approche n’est pas qu’un prétexte économique. Elle sert de garde-fou.
Penser un développement comme un produit exportable garantit qu’il répond à un besoin réel, et non à une habitude interne ou à un caprice isolé.
Aucune PME n’est assez unique pour que ses problèmes soient incomparables à ceux d’autres entreprises.
Donc, si une personnalisation Odoo est bien pensée, elle doit pouvoir avoir du sens ailleurs.
Cette contrainte a deux vertus :
Elle nous oblige à comprendre le rôle fondamental de chaque fonctionnalité dans le métier du client.
Elle nous pousse à concevoir sur le long terme, avec une logique de maintenance, d’évolution et de documentation.
Développer un module “commercialisable” n’est pas une stratégie de revente, c’est une discipline de conception : penser durablement, et non ponctuellement.
2. La logique de la pyramide inversée
Pour comprendre cette logique, il faut visualiser la structure d’Odoo comme une pyramide inversée.
À la base, on trouve le framework : le noyau qui définit ce qu’est un module, les règles du système, la gestion des utilisateurs, des autorisations et des vues.
Au-dessus, les modules fondamentaux : ceux qui représentent les grands objets de gestion — res.partner (les contacts), sale (les devis et les ventes), account (la comptabilité), purchase (les achats), etc.
Encore au-dessus, viennent les modules avancés, qui enrichissent les précédents.
Exemple : sale_subscription ajoute la notion d’abonnement au module sale.
Et enfin, au sommet, les modules spécialisés, créés par la communauté ou par des intégrateurs, pour des besoins métiers très précis.
Exemple : un module de construction qui numérote automatiquement les lots et sous-lots d’un devis (1, 1.3, 1.3.2).
Cette architecture montre une chose : Odoo ne refuse pas les besoins spécifiques, il les déplace vers les couches supérieures du système, là où la communauté ou l’intégrateur peuvent les concevoir librement.
Nous appliquons cette même philosophie : nos développements se placent certes au dernier niveau de la pyramide, mais doivent pouvoir en faire partie.
3. La mesure de la complexité
Vient ensuite la question centrale : combien cela coûte-t-il ?
Le chiffrage repose sur les spécifications techniques (combien de modèles, de vues, de contrôleurs, d’intégrations, de tests, de documentation), auxquelles on applique une unité de mesure commune : le jour-homme.
Chez Ekonum, cette base est fixée à 735 € par jour.
Mais il faut bien comprendre que la complexité d’un développement n’est pas proportionnelle à sa taille apparente.
Souvent, plus une demande semble simple, plus elle dissimule de ramifications.
Prenons deux exemples concrets :
Exemple 1 – Modifier le prix des rendez-vous selon le jour de la semaine.
Sur le papier, cela semble trivial : une liste de jours, une table de prix.
Mais dès qu’on entre dans le moteur, on découvre que les créneaux sont générés dynamiquement, que l’information doit être transmise au site web, au panier, à la facture, et que tout cela doit coexister avec les remises et les taxes.
Chaque “petit détail” se démultiplie en couches de dépendances.
Exemple 2 – Vendre des produits au kilo avec un poids fixe.
Là encore, on imagine un simple champ “poids”.
Mais derrière se cachent des règles de stock, des liens comptables, la nécessité de retirer du stock les produits commandés même non livrés, et des ajustements sur la marge.
Le besoin initial paraît fonctionnel ; la solution, elle, devient systémique.
C’est pour cela que les estimations augmentent toujours à mesure que la compréhension s’affine.
L’audit révèle la complexité latente : on ne découvre jamais un problème sans en créer trois nouveaux à comprendre.
4. La planification : entre méthode et instinct
Vient ensuite la planification.
On ne développe pas tout d’un bloc : on avance par itérations, de manière progressive et mesurée. Cette approche n’a rien de théorique. C’est la seule manière de construire sans désorganiser.
Concrètement, nous cherchons les fonctionnalités qui offrent la meilleure rentabilité client, c’est-à-dire celles qui apportent le plus de valeur au regard de leur coût.
Mais, à ce stade, la logique pure s’arrête : la planification est un exercice de jugement, pas de méthode.
Elle obéit à plusieurs forces de contrainte, dont certaines dépassent la technique :
La conduite du changement.
Quelle quantité de nouveauté une équipe peut-elle absorber à un moment donné ?
Une fonctionnalité rentable sur le papier peut être destructrice si elle bouleverse des habitudes trop vite.
Le calendrier opérationnel.
Certaines périodes de l’année sont propices à un changement (baisse d’activité, clôture terminée, vacances du personnel-clé), d’autres non.
On ne réforme pas une chaîne de production en plein pic de commandes.
La logique interne du système.
Certaines fonctionnalités dépendent d’autres.
Un module de facturation automatisée ne peut pas exister sans un modèle de vente cohérent ; une automatisation RH sans base de données collaborateurs fiable n’a aucun sens.
Ces trois forces ne sont pas exclusives — il en existe d’autres, souvent plus humaines que techniques : la fatigue des équipes, la culture d’entreprise, la résistance au changement, la tolérance au risque.
Là où l’audit est rationnel, la planification reste subjective. On peut tout mesurer, sauf les humains.
Alors, on suppose. On ajuste. On teste. On observe.
Le résultat n’est pas une équation exacte, mais un équilibre — celui d’un projet qui avance au rythme de ceux qui le vivront. La rigueur ne consiste pas à supprimer l’incertitude, mais à la reconnaître. C’est ce qui distingue une méthode honnête d’une promesse marketing.
5. Analyse du retour sur investissement : la tentation du chiffre et la réalité du bon sens
C’est ici que la plupart des cabinets de conseil sortent leur calculatrice et cessent de réfléchir.
Ils aiment les équations simples : “cette fonctionnalité coûte 10 000 €. Elle vous fera gagner 1 h par jour, donc elle sera rentable dans 18 mois.”
Ce type de raisonnement a le mérite d’être clair, mais il n’a aucune valeur : personne ne peut estimer sérieusement combien de temps une automatisation fera gagner avant de l’avoir testée dans la vraie vie.
Le retour sur investissement n’est pas un chiffre, c’est une zone de vraisemblance.
Notre approche consiste donc à inverser le problème : au lieu de prétendre calculer ce que la fonctionnalité fera gagner, nous cherchons à partir de quel gain minimum elle deviendrait rentable.
Ce raisonnement est plus humble, mais beaucoup plus honnête.
1. Calculer le point d’équilibre
On part du coût total d’une fonctionnalité, incluant son développement et son exploitation (maintenance, hébergement, mises à jour).
On le projette sur une durée de rentabilisation arbitraire — trois ans, cinq ans, peu importe, du moment que c’est cohérent avec la stratégie du client.
Puis on demande : combien de temps gagné par jour faudrait-il pour que ce soit rentable ?
Si la réponse est “0,12 seconde par semaine”, il faut probablement y aller.
Si la réponse est “26 heures par jour et par personne”, il faut probablement faire autre chose.
Ce raisonnement a le mérite d’être transparent : il ramène le discours à une réalité mesurable, même approximative.
2. Identifier les leviers de rentabilité
En réalité, une fonctionnalité peut rendre une entreprise plus rentable de seulement deux façons :
en faisant gagner de l’argent,
ou en empêchant d’en perdre.
Tout le reste — les discours sur “l’efficacité”, “l’agilité”, “la digitalisation” — ne sont que des reformulations de ces deux logiques.
Faire gagner de l’argent, cela signifie :
ouvrir un nouveau canal de vente (par exemple, vendre en ligne quand on ne vendait qu’en boutique) ;
augmenter le chiffre d’affaires existant (vendre plus, ou vendre plus cher).
Mais vendre plus cher suppose souvent d’améliorer la qualité du produit ou de changer de clientèle, ce que le logiciel permet rarement à lui seul.
Empêcher d’en perdre, c’est réduire les coûts, qu’ils soient variables ou fixes :
les coûts variables, qui augmentent avec l’activité (matières premières, logistique, main-d’œuvre de production) ;
les coûts fixes, indépendants du volume de clients (loyer, abonnements, charges salariales, etc.).
Or, la plupart des projets Odoo agissent sur une sous-catégorie précise de coûts fixes : le temps humain consacré à des tâches administratives.
Autrement dit, dans la plupart des cas, la promesse réelle d’un module personnalisé Odoo n’est pas “d’augmenter les ventes”, mais de rendre le temps des collaborateurs plus utile.
3. Modéliser un cas concret
Prenons un exemple volontairement terre-à-terre :
Une fonctionnalité coûte 10 000 € à développer, plus 2 000 € de maintenance annuelle.
On cherche à savoir si elle est rentable sur trois ans.
(10 000 € + 2 000 € × 3) / (3 ans × 220 jours ouvrés × 25 € de coût horaire) = 1 h gagnée par jour.
Autrement dit, si la fonctionnalité fait gagner une heure par jour à la personne concernée, elle s’amortit sur trois ans.
Si elle en fait gagner moins, elle détruit de la valeur.
Et si cette personne ne passait déjà que cent heures par an sur la tâche concernée, la conclusion est simple : la fonctionnalité n’est pas rentable. Il ne sert à rien d’automatiser ce qui n’est pas coûteux.
4. Les cinq leviers mesurables
En pratique, toutes les fonctionnalités qu’on étudie peuvent être ramenées à l’un des leviers suivants :
Chiffre d’affaires généré par un nouveau canal de vente
Chiffre d’affaires généré par l’amélioration de la qualité du produit
Chiffre d’affaires généré par la capacité à vendre plus
Temps économisé sur une opération
Temps économisé sur un projet
Or, une équation à cinq inconnues n’a pas pour solution un nombre. Alors on simplifie : on choisit un seul axe d'optimisation, et on considère que les autres sont neutres.
C’est une approximation, mais les TPE avec qui on travaille n'ont pas les moyens de payer 10 ans de consultants pour une analyse plus précise.
5. La limite du raisonnement
La vérité, c’est qu’on ne connaît la rentabilité d’une fonctionnalité qu’après sa mise en service.
Tout le reste n’est qu’hypothèse.
Mais ce n’est pas un problème : ce qui compte, c’est que ces hypothèses soient cohérentes, explicites et vérifiables.
Une entreprise rationnelle ne cherche pas à supprimer l’incertitude, mais à la réduire à un niveau acceptable.
Un bon audit ne promet pas la rentabilité ; il aide à décider lucidement dans l’incertitude.
C’est la seule promesse qui vaille.
Conclusion : l’audit comme exercice de lucidité
Un audit n’a pas pour objectif de “vendre du Odoo” ni de promettre une transformation numérique miraculeuse.
Il vise une chose beaucoup plus simple et plus difficile à la fois : aider le dirigeant à prendre des décisions rationnelles dans un environnement incertain.
Le raisonnement que nous avons construit suit toujours la même logique :
Comprendre comment l’entreprise fonctionne réellement (analyse des flux).
Mesurer la distance entre ce fonctionnement et ce que le logiciel permet (analyse des écarts).
Structurer cette distance en éléments concrets (spécifications techniques).
Évaluer l’effort nécessaire pour la combler (chiffrage).
Décider si l’effort en vaut la peine (analyse du retour sur investissement).
À travers ce processus, nous ne cherchons pas à éliminer l’incertitude, mais à l’encadrer.
Nous acceptons que certains choix relèvent du contexte, de la culture de l’entreprise ou du simple instinct — parce qu’une organisation, avant d’être un système, reste un ensemble d’humains.
L’audit devient alors un outil d’intelligence, pas un rituel administratif.
Il ne garantit pas la perfection, mais la lucidité.