Construire ou acheter : la grille que j'utilise quand une PME hésite

La question revient dans presque tous les cadrages avec une direction de PME, et elle est presque toujours posée sous une forme qui rend la réponse impossible : « est-ce qu’on achète une solution du marché ou est-ce qu’on fait développer ? » Posée ainsi, elle appelle une comparaison de coûts initiaux, et cette comparaison est tranchée d’avance. Un abonnement mensuel à quatre chiffres bat toujours un développement à cinq chiffres. Le raisonnement s’arrête là, la décision est prise, et l’entreprise découvre dix-huit mois plus tard que 3 personnes passent une partie de leur semaine à compenser à la main ce que l’outil ne sait pas faire.

Je ne prétends pas que le sur-mesure soit la bonne réponse. Dans la majorité des cas que je rencontre, il ne l’est pas, et je le dis en cadrage même quand cela me coûte un mandat. Mais la grille qui permet de trancher n’est pas celle du coût initial. Elle repose sur quatre questions, dont la première élimine à elle seule environ 75 % des cas.

La grille en quatre critères

Critère	On achète si…	On construit si…
Nature du processus	Commodité — le faire autrement n’apporte rien	Différenciant — c’est une raison de vous choisir
Coût de contorsion	Faible : la configuration suffit	Élevé : contournements manuels, renoncements
Sortie	Données exportables, règles documentées	Code possédé, technologies répandues, reprise testée
Capacité d’opération	L’éditeur maintient	Compétence interne ou contrat de maintien décidé d’emblée

Le premier critère élimine à lui seul environ 75 % des cas. Les trois suivants ne se posent que si la réponse au premier est « différenciant ».

Première question : ce processus est-il une commodité ?

La distinction structurante n’est ni technique ni budgétaire. Elle porte sur la nature du processus qu’on outille.

Un processus est une commodité quand le faire différemment de ses concurrents n’apporte aucun avantage. La paie, la comptabilité générale, la messagerie, la gestion des notes de frais entrent dans cette catégorie. Non parce qu’ils sont sans importance — une paie fausse est un problème grave — mais parce que l’excellence y consiste à être conforme et fiable, pas original. Construire un outil de paie sur mesure, c’est réinventer à ses frais un problème que des éditeurs résolvent depuis 30 ans, en héritant de l’obligation de suivre chaque changement réglementaire.

Un processus est différenciant quand la manière dont vous l’exécutez fait partie des raisons pour lesquelles vos clients vous choisissent. La façon dont un atelier ordonnance ses commandes en fonction des contraintes de matière. La manière dont une entreprise de service configure un devis complexe en tenant compte de règles que ses concurrents ne maîtrisent pas. La logique d’affectation des tournées d’une entreprise de livraison. Ces processus ne sont pas des commodités : ce sont des actifs.

La question à se poser est donc : standardiser ce processus revient-il à effacer ce qui nous distingue ? Si la réponse est non, on achète, et la discussion est close. Si la réponse est oui, on continue avec les trois questions suivantes.

Deuxième question : quel est le coût de la contorsion ?

C’est le poste que la comparaison initiale ignore systématiquement, parce qu’il ne figure sur aucune facture.

Un progiciel encode le processus de son éditeur, lequel représente une moyenne des pratiques de son marché. Chaque écart entre ce processus moyen et le vôtre doit être absorbé quelque part. Il l’est de quatre manières, par ordre croissant de dégât : par la configuration, quand l’outil le permet ; par la formation, quand il faut apprendre aux équipes une manière de faire différente de la leur ; par le contournement manuel, quand une personne ressaisit dans un tableur ce que l’outil ne sait pas produire ; et par le renoncement, quand l’entreprise abandonne une pratique qui lui était propre parce que le logiciel ne la supporte pas.

Les deux dernières formes sont les plus coûteuses et les moins visibles. Elles ne se manifestent pas comme une dépense mais comme une érosion : des heures de saisie, des délais allongés, une donnée qui existe en deux versions, et parfois la disparition silencieuse de l’avantage qu’on avait.

Chiffrer ce coût est possible et ce n’est pas long. On liste les écarts connus entre le processus réel et ce que l’outil prévoit, on estime pour chacun le temps humain consommé par semaine, et on multiplie par 3 ans. Le résultat déplace fréquemment la comparaison. Il ne l’inverse pas toujours, mais il la rend honnête.

Un progiciel configuré épouse le processus de son éditeur ; il faut plier l’entreprise à l’outil. Un outil sur mesure épouse le processus réel de l’entreprise, et vieillit avec lui. Toute la question est de savoir lequel des deux mérite d’être préservé.

Troisième question : à quoi ressemble la sortie ?

La troisième question est celle de la réversibilité, et elle se pose des deux côtés — ce qu’on oublie souvent, en la traitant comme une objection réservée au sur-mesure.

Côté progiciel, la sortie s’évalue à trois choses : peut-on extraire l’intégralité de ses données dans un format exploitable, la logique métier configurée est-elle documentée ailleurs que dans l’interface de l’éditeur, et combien de temps prendrait une migration. Un outil qui détient vos données dans un modèle propriétaire, dont les règles de gestion n’existent que sous forme de cases cochées dans une interface, et dont l’export se limite à un fichier tabulaire appauvri, vous coûtera très cher à quitter. La dépendance n’est pas moins réelle parce qu’elle est contractuelle plutôt que technique.

Côté sur-mesure, la sortie s’évalue à la reprenabilité. Le code est-il la propriété du client et déposé chez lui ? Les technologies sont-elles suffisamment répandues pour qu’un autre prestataire puisse intervenir ? L’architecture est-elle documentée ? Une procédure de reprise a-t-elle été testée au moins une fois, plutôt que promise ?

Le risque du sur-mesure est réel — c’est celui de dépendre d’une personne. C’est l’arbitrage que j’ai traité sous l’angle du prestataire dans Atelier solo contre agence-fabrique. Mais il se traite contractuellement, et un sur-mesure correctement livré est reprenable. S’il ne l’est pas, le problème n’est pas l’approche : c’est la manière dont elle a été exécutée, et c’est un critère de choix du prestataire.

Quatrième question : l’organisation saura-t-elle l’opérer ?

La dernière question est la plus déterminante à long terme et la moins posée.

Un outil sur mesure n’est pas livré une fois. Il vit : il évolue avec le processus qu’il outille, il exige des correctifs, des montées de version de ses dépendances, une surveillance. Une entreprise qui n’a ni compétence interne, ni contrat de maintien durable, se retrouvera dans 3 ans avec un logiciel qui fonctionne mais que plus personne ne touche — figé au moment où l’entreprise, elle, a continué de changer. Le sur-mesure devient alors le pire des deux mondes : la rigidité d’un progiciel, sans l’éditeur qui le maintient.

Cette question ne disqualifie pas le sur-mesure ; elle en conditionne la forme. Une entreprise sans capacité technique interne peut parfaitement commander du sur-mesure, à condition que le contrat de maintien soit décidé en même temps que la construction, et non 3 ans plus tard dans l’urgence.

Pourquoi la bonne réponse est presque toujours mixte

En pratique, la conclusion de cette grille est rarement binaire, et c’est le point que je défends le plus souvent en cadrage.

On achète les commodités — comptabilité, paie, messagerie, gestion documentaire, souvent la vitrine de commerce elle-même. On construit uniquement la couche qui porte la différenciation, et on la branche sur les progiciels par leurs interfaces. Le périmètre du sur-mesure se réduit alors à ce qui le justifie réellement : ce qui divise le coût, réduit la surface de maintenance, et concentre l’investissement là où il produit un avantage.

C’est aussi la raison pour laquelle la question que je pose en cadrage n’est jamais « quel logiciel installer ». C’est : ce processus mérite-t-il un outil qui durera 10 ans. Quand la réponse est non, le progiciel est la bonne décision et je le dis. Quand elle est oui, il reste à vérifier que l’entreprise saura le porter — et cette vérification-là précède le devis¹.

---

Footnotes

1. Sur le choix du socle technique quand la réponse penche vers le sur-mesure, et sur les conditions dans lesquelles ce choix se rembourse, voir NestJS et Angular : le socle des applications métier qui durent. ↩