« On préférerait développer en interne, comme ça c'est vraiment à nous. » Cette phrase, je l'entends dans un rendez-vous sur trois. Elle est presque toujours suivie d'une deuxième, quelques mois plus tard, avec un ton différent : « on a un outil qui marche à peu près, mais celui qui l'avait fait est parti. »
Le débat build ou buy n'a rien de nouveau. Ce qui a changé, c'est qu'assembler soi-même une brique IA est devenu si facile que la question ne se pose plus au moment où elle devrait. On construit d'abord, on se demande après si c'était le bon choix.
La seule question qui compte vraiment
Est-ce que ce cas d'usage fait partie de ce qui te différencie sur ton marché ?
Si la réponse est non — et elle est non dans l'écrasante majorité des cas — tu achètes. Ta facturation, ton support de niveau 1, ta comptabilité, ta transcription de réunions, ta relecture de contrats : d'autres l'ont fait, mieux, pour moins cher, et ils continueront de l'améliorer sans toi. Le fait que tu puisses le construire ne veut pas dire que tu doives le construire.
Si la réponse est oui, la question devient légitime. Elle ne devient pas automatiquement positive.
La grille de décision, en trois questions
1. Est-ce ton cœur de métier ?
Un cabinet de conseil qui construit son propre outil de facturation perd du temps. Un cabinet qui construit son propre moteur d'analyse de documents sectoriels, sur une méthode qui lui appartient, investit dans ce qu'il vend.
Le test que j'utilise : est-ce que ce que fait cette brique apparaît dans ta proposition commerciale ? Si oui, c'est un actif. Si non, c'est de la plomberie, et on n'achète pas une usine pour fabriquer ses propres tuyaux.
2. As-tu une donnée propriétaire à exploiter ?
C'est le vrai facteur discriminant, et le plus souvent négligé. Un outil du marché branché sur un modèle générique fait la même chose chez toi que chez ton concurrent. La différence ne peut venir que de ce que toi seul possèdes : un historique de dossiers annotés sur dix ans, un référentiel produit que personne d'autre n'a, une base de retours clients structurée, un savoir-faire d'estimation que tes anciens ont formalisé.
Sans cette matière, construire revient à refaire, moins bien, ce qui existe déjà. Avec cette matière, l'outil du marché ne saura jamais l'utiliser aussi bien que toi.
Attention à l'auto-illusion sur ce point : beaucoup d'entreprises croient avoir une donnée propriétaire alors qu'elles ont un tas de PDF non structurés. Passe-les d'abord aux tests de faisabilité — extraction, cohérence, fraîcheur.
3. Que coûte la maintenance sur trois ans ?
C'est la question qui tue les projets de build en PME, et personne ne la pose au départ.
Une brique IA maison, ça se maintient :
- Les modèles évoluent. Ce que tu as calibré cet automne se comporte différemment au printemps suivant.
- Les API changent, les tarifs bougent, un fournisseur déprécie une version.
- Le processus métier bouge, et il faut adapter les règles.
- Les cas non prévus arrivent, et quelqu'un doit décider quoi en faire.
Traduis ça en jours-homme par an, et surtout en dépendance à une personne. La question qui fait réfléchir mes clients : si celui qui a construit ça part en juin, qu'est-ce qui se passe ? Si la réponse est « on est bloqués », le coût réel n'est pas dans le devis.
Pourquoi la plupart des PME devraient acheter
Trois raisons, sans nuance.
D'abord parce que le marché s'est étoffé. Il existe aujourd'hui des outils spécialisés pour la majorité des processus transverses, à des tarifs sans rapport avec un développement sur mesure.
Ensuite parce qu'une PME n'a pas de banc de maintenance. Un logiciel interne qui n'a pas de propriétaire dédié se dégrade lentement, et le jour où il casse, il casse un jour où personne n'a le temps.
Enfin parce que le vrai gain, en PME, ne vient presque jamais de la sophistication de l'outil. Il vient de la clarté du processus et de l'adoption par les équipes. Ce travail-là, tu dois le faire dans les deux cas — autant y consacrer ton énergie plutôt qu'à réécrire une brique.
Les cas où construire se justifie
Ils existent, et ils sont reconnaissables :
- Le cas d'usage est ton produit. Ce que tu vends, c'est ça. Il n'est pas question de le sous-traiter.
- Aucun outil ne couvre ton métier. Marché de niche, réglementation particulière, vocabulaire spécifique. Tu as regardé sérieusement, pas dix minutes.
- Ta donnée propriétaire est réellement structurée et exploitable, et c'est elle qui crée l'écart.
- Les contraintes de confidentialité l'imposent et aucune solution du marché ne les satisfait. Sur ce point, fais valider par un juriste : ce que j'écris ici n'est pas un avis juridique.
Il y a aussi une voie intermédiaire, souvent la meilleure : acheter la fondation et construire par-dessus. Un outil du marché pour la mécanique, une couche maison légère pour ce qui te distingue. Tu gardes la spécificité, tu délègues la maintenance de l'infrastructure.
Une nuance depuis mon propre atelier
J'ai construit seule deux produits en no-code assisté par IA : Wavestay, réservation d'hébergements pour riders de kitesurf et de surf, et Pulse Outdoor Training Club, réservation de sessions de sport en plein air. Lovable pour le build, Claude pour la conception et les itérations.
Donc oui, construire est plus accessible qu'avant, et je ne vais pas prétendre le contraire. Mais dans les deux cas, le produit était l'affaire — pas un support de l'affaire. Et je suis la propriétaire, la mainteneuse et l'utilisatrice. C'est exactement la configuration où le build se tient. Ce n'est pas celle d'une PME de trente personnes qui veut automatiser ses relances de factures.
Le test avant ton prochain arbitrage
Écris une phrase : « nous construisons ceci nous-mêmes parce que ______ ». Si le blanc se remplit avec « c'est ce qui nous différencie » et « nous avons la donnée que personne d'autre n'a », construis. S'il se remplit avec « ça coûte moins cher » ou « on a quelqu'un qui sait le faire », achète.