Quand construire devient facile, on construit trop. C'est le risque principal de la période actuelle : accumuler des dizaines d'outils internes rapidement produits, que personne ne maintient et que personne ne comprend six mois plus tard. La bonne question n'a jamais été « puis-je le faire », mais « qui s'en occupera dans deux ans ».
Nous rapportions ce matin qu'un tiers des organisations ont renoncé à acheter un logiciel parce qu'elles pouvaient le construire. Voici comment décider sans le regretter.
Question 1 : est-ce spécifique à vous ?
C'est le critère le plus discriminant. Un outil qui épouse votre manière de travailler, vos champs, votre vocabulaire métier, n'existe pas sur le marché — ou existe en version générique qui vous obligera à adapter vos processus au logiciel.
Construisez ce qui est propre à votre organisation. Achetez ce que tout le monde fait pareil : la comptabilité, la paie, la messagerie.
Question 2 : qui en répond si ça tourne mal ?
Un logiciel acheté vient avec un contrat, un support et une responsabilité. Un outil interne vient avec vous.
Pour tout ce qui touche à des obligations réglementaires, à des données de santé, à des décisions concernant des personnes, cette différence est déterminante. Nous l'avons vu à propos du recrutement : certaines applications relèvent de régimes exigeants, et une conformité se démontre.
Question 3 : la valeur vient-elle du code ou d'autre chose ?
Beaucoup de logiciels ne valent pas par leur code mais par ce qui vient avec : une base de données que vous n'avez pas, un réseau d'utilisateurs, des intégrations maintenues avec cinquante autres systèmes, une certification.
Ces éléments ne se reproduisent pas avec un outil de codage, quelle qu'en soit la puissance. C'est la logique de Thomson Reuters : le corpus est l'actif, pas le logiciel.
C'est la question qu'on saute et qui coûte le plus cher. Un outil interne doit être corrigé quand une API change, mis à jour quand une faille apparaît, documenté pour ceux qui arriveront, et repris quand son auteur part. Une règle empirique utile : la maintenance coûte davantage sur la durée de vie que la construction initiale, et cet écart s'accroît quand la construction devient rapide. Si vous ne pouvez pas nommer la personne qui s'en occupera dans dix-huit mois, n'écrivez pas cet outil.
Question 5 : quel est le coût du changement d'avis ?
Un outil interne se modifie quand vous voulez. Un logiciel acheté se subit, jusqu'au renouvellement.
Mais l'inverse existe aussi : un outil acheté s'abandonne en résiliant, un outil interne mal conçu vous accompagne longtemps parce que personne n'ose y toucher.
La vraie question est donc la réversibilité dans les deux sens, et elle rejoint le principe que nous répétons : ce qui compte n'est pas le bon choix aujourd'hui, c'est la capacité d'en changer demain.
La troisième voie, souvent la meilleure
Le débat est rarement binaire. La configuration la plus solide consiste souvent à acheter la base et construire la couche fine : un logiciel du marché pour ce qui est standard, un outil interne léger pour ce qui vous est propre, reliés par des interfaces.
C'est aussi ce qui limite le risque : si votre couche interne devient ingérable, vous la jetez sans perdre le socle.
Ce qu'il faut retenir
Les outils agentiques ont réduit le coût de la construction, pas celui de la possession. Ce sont deux choses différentes, et confondre les deux est l'erreur la plus fréquente en ce moment.
Le test le plus honnête tient en une phrase : imaginez que la personne qui va écrire cet outil quitte l'entreprise dans six mois. Si vous pouvez encore répondre à « qui reprend », construisez. Sinon, achetez, même si c'est moins bien ajusté.