Vos devis sont dans un logiciel, le stock dans un tableur, la comptabilité ailleurs, et quelqu'un recopie les mêmes informations trois fois par semaine. Vient le moment de choisir un ERP, un seul logiciel pour tout relier. Le marché est plein d'offres pour les PME, chaque éditeur a une démonstration impeccable, et vous n'avez pas de DSI pour trier.
Je ne suis pas intégrateur et je ne fais pas de refonte d'ERP. Je travaille du côté du client, sur les spécifications et les intégrations entre logiciels. Ce qui suit, c'est ce que je prépare avant qu'un éditeur montre quoi que ce soit, et ce que je regarde ensuite pour départager les offres.
01Avant l'ERP, écrire comment l'entreprise travaille vraiment
Quand un projet d'ERP dérape, le logiciel est rarement le premier en cause, et l'éditeur lui-même le dit. Dans un webinaire de l'éditeur, l'équipe d'implémentation d'Odoo cite parmi les premières causes d'échec un recueil des besoins trop léger et des processus mal définis : les besoins exprimés sont faux parce que l'entreprise n'a jamais écrit comment elle travaille. L'intégrateur comprend la demande, mais la demande ne décrit pas la réalité.
Je commence donc par une page, pas par un comparatif. Pour chaque flux (un devis devient une commande, une commande sort du stock, une facture part, un fournisseur est payé), j'écris qui fait quoi, dans quel outil aujourd'hui, et ce qui coince. Je le fais avec les personnes qui préparent les commandes et tiennent la comptabilité, pas seulement avec le dirigeant.
Cette page évolue vite, et c'est normal. Sur une intégration entre un ERP et un site marchand, la spécification a bougé presque à chaque réunion. Je l'ai versionnée, pour que tout le monde parle du même document. Je détaille cette façon de faire dans ma méthode pour écrire une spécification d'intégration.
Dans mes machines de contenu, la rédaction ne démarre pas tant que le brief n'est pas complet : l'outil répond « refusé » et liste ce qui manque. Je fais la même chose ici. Tant que les flux ne sont pas écrits, je ne demande pas de démonstration.
02Ce qu'un ERP pour PME doit couvrir, et ce qu'il peut laisser à d'autres
France Num, le service de l'État pour la transformation numérique des petites entreprises, résume bien le périmètre : achats, finance, commercial, logistique, ressources humaines. Il rappelle aussi la contrepartie : un ERP est souvent moins riche que les logiciels spécialisés qu'il remplace, et il peut obliger l'entreprise à s'adapter à l'outil.
Je ne vise donc pas un ERP qui fait tout. Je cherche celui qui fait bien le cœur de l'activité, et je garde à côté ce qui marche déjà. Si votre logiciel de paie ou votre boutique en ligne vous conviennent, la question devient : l'ERP saura-t-il échanger avec eux, et qui sera maître de chaque donnée ? Pour un site marchand, j'ai décrit ces décisions dans l'article sur le connecteur entre Odoo et PrestaShop.
Vous ne serez pas seul à vous poser la question. Selon Eurostat, 41 % des petites entreprises de l'Union utilisaient un ERP en 2025, contre 89 % des grandes. Beaucoup de PME en sont donc à leur premier ERP, sans équipe interne pour le choisir.
03Les critères de choix d'un ERP qui départagent vraiment
Les listes de critères sont longues. Celle de France Num en compte une dizaine, toutes légitimes. Sur le terrain, j'en vois six qui font vraiment la différence entre deux offres.
- La couverture de vos besoins prioritaires, en standard. Je classe les besoins en trois niveaux : indispensable, utile, confort. Un ERP qui demande un développement pour un besoin indispensable part avec un handicap.
- Les échanges avec vos autres outils. Je demande par quelle API, sur quelle formule d'abonnement, et qui écrit le connecteur. Chez Odoo par exemple, la documentation indique que l'accès à l'API externe est réservé aux formules Custom, pas aux formules One App Free ni Standard. C'est le genre de détail qu'on découvre trop tard.
- Le standard plutôt que le spécifique. Le même webinaire d'Odoo pose comme premier principe de rester le plus standard possible, et décrit la dérive par petites personnalisations successives qui allonge le projet sans fin.
- L'hébergement et le lieu des données. France Num conseille de privilégier des données hébergées dans l'Union européenne, au regard du RGPD.
- Le coût des mises à niveau, que je détaille plus bas.
- L'intégrateur autant que le logiciel. C'est lui que vous appellerez quand une facture ne sort pas. France Num note qu'avec une solution open source, il est plus facile de changer d'intégrateur en cas de difficulté.
L'ergonomie compte aussi, mais je la juge pendant la démonstration, avec les futurs utilisateurs dans la salle.
04Faire jouer vos propres cas en démonstration
Une démonstration d'éditeur montre le parcours qui marche. Ce n'est pas malhonnête, c'est son métier. Le vôtre est de lui faire jouer vos cas, avec vos données.
Préparer une dizaine de cas réels
Je tire de la page des flux une dizaine de situations vraies, dont au moins trois pénibles : une commande livrée en deux fois, un avoir partiel, un article vendu au carton et stocké à l'unité. Ce dernier type de cas mérite une attention particulière. Sur un projet, un mélange de centimètres et de millimètres entre deux outils déformait tout un rendu. Depuis, je demande que la donnée de référence soit explicite, unité comprise.
Les jouer sur vos données, pas sur la base de démonstration
J'envoie les cas et un extrait de vraies données une semaine avant. Je demande à chaque candidat de les dérouler devant la personne qui fera ce travail chaque jour. Je note ce qui tourne en standard, ce qui demande un paramétrage et ce qui demande du développement.
Cette idée vient d'un travail chez Moonworkers, ma propre entreprise. Un oracle écrit à partir des textes officiels a rejoué plusieurs centaines de cas de cotisations et trouvé quatre erreurs d'un penny, dues à une règle d'arrondi. Aucune démonstration ne les aurait montrées. Je raconte ce travail dans l'article sur les tests par oracle.
Garder les cas pour la recette
Ces cas ne servent pas qu'au choix. Ils deviennent la base de la recette, ce moment où, comme le dit le webinaire d'Odoo, le client teste ses cas limites avant de valider. Ma checklist de recette et de mise en production part du même principe : on vérifie comme un utilisateur réel, pas comme l'équipe qui a construit l'outil.
05Les coûts qui ne figurent pas dans le devis
Le devis montre l'abonnement et le paramétrage de départ. France Num met en garde contre les coûts cachés des formules « tout compris » : la formation, la maintenance, les montées de version. J'ajoute trois postes que je fais chiffrer à part.
Les mises à niveau d'abord. La documentation d'Odoo indique que chaque version majeure est prise en charge pendant trois ans, et qu'une base qui contient des modules personnalisés ne peut pas être mise à niveau tant que ces modules n'existent pas pour la version cible. Chaque développement spécifique d'aujourd'hui est donc un chantier de migration à venir. Je demande qui le portera, et à quel rythme.
La reprise des données ensuite. Le webinaire d'Odoo le dit sans détour : un ERP alimenté avec de mauvaises données donne de mauvais résultats. Nettoyer les fiches clients, les articles et les stocks prend du temps, et ce temps est rarement dans le devis.
La formation enfin, et le temps de vos équipes. L'équipe d'Odoo forme quelques utilisateurs clés, qui deviennent la référence en interne. C'est une bonne pratique, mais ces personnes passent alors des journées sur le projet au lieu de leur travail habituel. Il faut le prévoir.
Une limite honnête : cette préparation demande du temps interne, souvent plusieurs semaines, avant la première démonstration. Pour une très petite structure avec un seul flux simple, c'est trop. Un essai gratuit et une journée de tests suffisent souvent. Et si votre projet ressemble à une refonte lourde avec des dizaines de sites, il vous faut un intégrateur et une équipe dédiée, pas seulement un cadrage.
06Par où commencer lundi
Prenez une feuille et listez vos cinq flux principaux. Pour chacun, notez qui le fait, dans quel outil, et ce qui coince aujourd'hui. Faites-le avec les personnes qui font le travail. Choisissez ensuite trois cas pénibles que vous voudrez voir tourner en démonstration. Si vous écrivez un document de consultation, la structure de mon modèle de cahier des charges s'adapte assez bien à un ERP.
Vous n'avez pas besoin de connaître les éditeurs pour commencer. Vous avez besoin de savoir comment votre entreprise travaille. Si vous voulez quelqu'un pour écrire ces flux avec vous, préparer les cas et suivre le choix côté client, mes services de direction de projet et de direction technique sont décrits sur le site, et le portfolio montre le reste. On peut en parler.