Un développement Odoo n'est jamais une opération purement technique quand il touche la facturation, la TVA, les salaires ou la comptabilité. Il engage l'entreprise sur la durée, avec des obligations légales suisses qui ne se négocient pas avec un cahier des charges. Sur le marché romand, cette réalité oppose souvent deux profils : les intégrateurs qui maîtrisent le code d'Odoo sans connaître le plan comptable suisse, la QR-facture ou les normes Swissdec ; et les fiduciaires qui maîtrisent la comptabilité mais ne développent rien elles-mêmes, renvoyant chaque demande de personnalisation à un tiers. AX-Fiduciaire, partenaire officiel Odoo, réunit les deux compétences dans la même équipe : le développement (modules, champs, workflows, rapports, connecteurs) et l'expertise fiduciaire (comptabilité, TVA, salaires, conformité suisse). Cette page présente notre développement Odoo sur mesure : ce qu'il couvre, la méthode suivie, et les limites que nous posons nous-mêmes.
Quand un développement sur mesure se justifie
Odoo standard couvre une part large des besoins de gestion d'une PME : comptabilité, facturation, achats, stocks, ventes, ressources humaines. Une partie de ces besoins se règle sans écrire une ligne de code, par le paramétrage ou par Odoo Studio. Un développement sur mesure ne se justifie que lorsque ces options sont épuisées : un processus métier réellement spécifique à l'entreprise, une règle de gestion que le standard ne prévoit pas, un connecteur vers un système externe qui n'existe sous aucune forme de module, ou un document dont la structure ne correspond à aucun modèle fourni.
À l'inverse, un développement ne se justifie pas quand :
- le besoin est déjà couvert par le paramétrage standard (champs additionnels, règles de facturation, séquences, droits d'accès) ;
- Odoo Studio permet d'ajouter le champ, la vue ou l'automatisation sans toucher au code source ;
- un module OCA (Odoo Community Association) existant répond au besoin, avec l'avantage d'être maintenu par une communauté plutôt que par un seul prestataire ;
- le besoin réel est un changement d'habitude de travail, pas une limite du logiciel.
Cette discipline conditionne la survie du développement dans le temps. Un module ajouté pour reproduire une habitude plutôt que pour répondre à une contrainte réelle devient, à la première montée de version majeure, un poste de travail supplémentaire sans justification claire. Le critère déterminant n'est pas le nombre de fonctions qu'un développement peut ajouter, mais sa capacité à traverser les futures versions d'Odoo. Odoo 19 est la version stable actuelle ; Odoo 20 est dévoilée le 24 septembre 2026. Chaque développement sur mesure doit être pensé pour cette continuité, pas seulement pour répondre au besoin du jour.
Cette question se pose avec une acuité particulière dès qu'un module touche à la comptabilité, à la TVA ou à la paie. Un champ ajouté sur une facture, une règle de calcul insérée dans un workflow de validation, ou une automatisation qui modifie une écriture comptable ne sont jamais des développements anodins : ils s'exécutent à chaque transaction, souvent sans supervision humaine directe. La question à se poser avant tout développement n'est donc pas seulement « est-ce possible », mais « ce développement restera-t-il correct dans deux ans, avec une équipe différente, sur une version d'Odoo différente ». C'est cette question, plus que la faisabilité technique, qui distingue un développement pertinent d'un développement qui deviendra un problème.
Ce qu'il est possible de développer dans Odoo
Le développement sur mesure dans Odoo recouvre plusieurs niveaux, du plus simple au plus structurant. Ils se combinent souvent dans un même projet : un connecteur s'accompagne presque toujours d'un nouveau modèle de données pour stocker ce qu'il reçoit, un workflow modifie généralement une vue pour rester lisible.
Modules
Un module Odoo regroupe un ensemble cohérent de fonctionnalités : modèles de données, vues, règles métier, droits d'accès. Un module sur mesure s'installe à côté des modules standards sans les modifier, ce qui limite l'impact sur les futures montées de version. C'est le niveau que nous privilégions par défaut, plutôt que d'intervenir directement dans le code des modules fournis par Odoo.
Champs et modèles
Ajouter un champ à un formulaire existant, créer un nouveau modèle de données pour suivre une information propre à l'entreprise (un numéro de dossier, une catégorie interne, un statut spécifique), et relier ces informations aux modèles existants — clients, factures, commandes, employés. C'est souvent le point de départ d'un développement plus large : une fois l'information stockée, elle doit être affichée, filtrée, et parfois reportée dans un document.
Vues
Adapter l'affichage d'un formulaire, d'une liste ou d'un tableau de bord pour qu'il corresponde au flux de travail réel de l'équipe, sans surcharger l'interface standard d'options inutiles pour les autres utilisateurs. Une vue mal pensée, ajoutée pour un seul poste de travail, finit souvent par gêner tous les autres.
Workflows et automatisations
Automatiser un enchaînement d'étapes — validation, notification, changement de statut — selon des règles propres à l'entreprise, dans les limites où l'automatisation reste compréhensible et corrigible par un humain. Une automatisation opaque, que personne ne sait expliquer ni corriger, pose un risque supérieur au gain de temps qu'elle procure.
Rapports et documents
Concevoir des documents imprimés ou PDF (factures, bulletins, bons de livraison, rapports d'analyse) qui respectent une charte graphique ou une structure d'information particulière, tout en restant générés depuis les données réelles d'Odoo, jamais depuis une source parallèle qui risquerait de diverger.
Connecteurs et API
Relier Odoo à un système externe — banque, caisse enregistreuse, plateforme e-commerce, outil métier tiers — via l'API Odoo (XML-RPC, JSON-RPC ou REST selon les cas) ou via des connecteurs dédiés aux standards suisses de paiement, ISO 20022 et QR-facture. Un connecteur mal isolé peut faire échouer une synchronisation entière pour une erreur mineure côté système externe ; l'analyse d'impact, décrite plus bas, sert précisément à limiter ce risque.
Portails
Ouvrir un accès limité et sécurisé à des tiers — clients, fournisseurs, employés — pour consulter ou déposer des documents, sans leur donner accès à l'interface complète de gestion. Les droits d'accès du portail doivent être définis avec la même rigueur que ceux d'un utilisateur interne.
La méthode suivie pour chaque développement
Un développement Odoo qui touche des données de gestion suit une séquence de travail fixe, quelle que soit sa taille.
| Étape | Objectif |
|---|---|
| Cadrage du besoin | Comprendre le processus réel, distinguer ce qui relève du paramétrage standard de ce qui justifie un développement. |
| Analyse d'impact | Identifier les modules standards concernés, les risques sur les futures montées de version, et les alternatives existantes (Studio, module OCA). |
| Spécification | Décrire précisément les champs, règles, vues et documents concernés, validés avant tout développement. |
| Développement | Écriture du code dans un module dédié, sans modification des modules standards. |
| Tests | Vérification fonctionnelle et tests de non-régression sur les processus existants. |
| Recette | Validation par les utilisateurs métier sur un environnement de test, avant mise en production. |
| Mise en production | Déploiement planifié, avec un point de retour possible en cas d'anomalie. |
| Maintenance | Suivi du développement dans la durée, y compris lors des montées de version. |
Deux étapes de cette méthode sont souvent négligées par les intégrateurs qui ne connaissent pas la comptabilité suisse : l'analyse d'impact, qui doit inclure une lecture des conséquences comptables et fiscales du développement, et la recette, qui doit être validée par une personne capable de juger si le résultat produit est correct au sens comptable, pas seulement au sens fonctionnel.
La contrainte suisse : ce que la double compétence change
Un développement qui touche la comptabilité, la TVA ou la paie n'est jamais un développement neutre. Il doit respecter le plan comptable retenu par l'entreprise, les positions fiscales appliquées à chaque type d'opération, la structure de la QR-facture, le standard de paiement ISO 20022, et les exigences Swissdec pour la gestion des salaires. Un champ ajouté sans tenir compte de ces contraintes peut produire une écriture comptable fausse, une position TVA incorrecte, ou une QR-facture non conforme.
Odoo installe automatiquement la localisation suisse (module l10n_ch) lorsque la société est configurée en Suisse, ce qui pose une base correcte pour le plan comptable et les taux de TVA — 8.1 %, 2.6 % et 3.8 % depuis le 1er janvier 2024. Cette base standard ne dispense pas de vérifier, à chaque développement, que la personnalisation reste alignée avec elle plutôt que de la contourner.
Sur la paie, Odoo figure au registre Swissdec au niveau « swissdec certified basic » (certificat n° 1203.25, pour ELM 5.3, vérifié le 22.09.2026). Un développement qui touche le calcul ou la transmission des salaires doit respecter ce cadre de certification : ce n'est pas un domaine où l'on peut se permettre une adaptation qui s'écarte du standard certifié. C'est précisément à cette intersection que la double compétence d'AX-Fiduciaire compte : comprendre à la fois ce que le code doit faire et ce que la loi suisse exige de ce résultat. Nos développements qui touchent la comptabilité s'articulent avec notre offre comptabilité Odoo ; ceux qui touchent les salaires, avec notre offre paie et RH Odoo.
Maintenir un développement dans le temps
Un développement livré n'est pas un développement terminé. Il vit avec le reste du système et doit rester compatible avec ses évolutions. C'est un point que les projets pilotés uniquement par la mise en production initiale négligent souvent : le coût d'un développement ne se mesure pas seulement à sa livraison, mais à ce qu'il coûte de le maintenir sur plusieurs versions successives.
- Montées de version : chaque nouvelle version majeure d'Odoo peut modifier des API, des modèles ou des vues sur lesquels un module sur mesure s'appuie. Un module bien conçu, sans modification des modules standards, limite ce risque sans l'éliminer. Voir notre offre migration Odoo.
- Dette technique : chaque développement ajouté augmente la surface à maintenir. Un développement non documenté, non testé ou redondant avec le standard devient une charge qui s'accumule.
- Tests de non-régression : vérifier, à chaque mise à jour, que les développements existants continuent de fonctionner comme prévu.
- Documentation : consigner ce qui a été développé, pourquoi, et selon quelles règles métier, pour qu'un autre développeur puisse reprendre le travail sans deviner les intentions d'origine.
- Réversibilité : un développement doit pouvoir être désactivé ou retiré sans casser le reste du système, si le besoin qui l'a motivé disparaît.
Ce suivi dans la durée s'inscrit dans notre offre de support Odoo, qui couvre aussi bien les modules standards que les développements réalisés par AX-Fiduciaire.
Reprendre un développement existant fait par un autre prestataire
Nous intervenons aussi sur des développements Odoo réalisés par un prestataire précédent, qu'il s'agisse de corriger une anomalie, de préparer une montée de version, ou de reprendre la maintenance d'un système dont le prestataire d'origine n'est plus disponible. Cette reprise commence toujours par une analyse du code existant : ce qu'il fait réellement, comment il a été construit, s'il modifie des modules standards ou s'il vit dans des modules séparés, et quels risques il présente pour les futures montées de version.
Cette analyse peut montrer qu'un développement existant est solide et mérite d'être conservé tel quel, qu'il doit être documenté avant toute intervention supplémentaire, ou qu'il doit être partiellement révisé parce qu'il modifie directement des modules standards ou contourne une règle comptable. Dans tous les cas, la reprise se fait sur la base de ce qui existe, pas d'une réécriture systématique.
Ce type d'intervention est fréquent après une montée de version qui révèle des développements devenus incompatibles, ou lorsqu'un développement touchant la comptabilité ou la paie a été réalisé par un prestataire sans expertise fiduciaire et doit être vérifié sur le fond, pas seulement sur la forme du code.
Ce qu'AX-Fiduciaire ne fera pas
Ces limites sont posées dès le cadrage du besoin, pas découvertes en cours de projet.
- Développer ce que le standard couvre déjà. Si un paramétrage, une option native ou un module OCA existant répond au besoin, nous ne proposons pas un développement sur mesure à la place.
- Contourner une règle comptable, fiscale ou de paie par du code. Un développement ne sert jamais à produire un résultat qui s'écarte du plan comptable, des positions TVA ou des exigences Swissdec applicables.
- Livrer sans tests. Un développement qui touche des données de gestion passe par des tests fonctionnels et des tests de non-régression avant sa mise en production, sans exception.