L’outil dont nous avons besoin n’existe pas, et en acheter un ne convient pas
Quand chaque produit du marché couvre 70 % et rate la partie qui compte vraiment, bâtir la pièce manquante est désormais une option raisonnable. L’ingénierie assistée par l’IA a fait passer les petites applications internes de « ça ne vaut pas un projet » à quelques semaines de travail.
Est-ce vraiment moins cher de bâtir que d’acheter ?
Pour un outil interne restreint, de plus en plus oui — mais la comparaison honnête n’oppose pas le coût de la licence au coût de construction. C’est le total de la licence, des contournements pour les 30 % qu’elle ne fait pas, de l’intégration que personne n’a budgétée, et du processus que votre équipe pliera pour s’adapter au produit.
Ce qui a changé, c’est le coût de la construction, pas le coût de son maintien. Une application produite rapidement et que personne ne comprend est un passif, peu importe comment elle a été faite. La question à se poser n’est donc pas « pouvons-nous bâtir ça ? » mais « pourrons-nous encore la modifier dans deux ans ? »
L’écart reste rarement à un seul endroit. Quand un produit couvre l’essentiel des besoins de quatre équipes, chacune bâtit sa propre version du reste : un chiffrier ici, un script là, une application ailleurs. Aucune ne sait que les autres avaient le même problème. Le coût n’est pas l’outil qui a été bâti. Ce sont les trois qui n’avaient pas à l’être.
Ne l’avons-nous pas déjà bâti, dans un chiffrier ?
Oui. Avant le générateur d’applications, l’outil rapide, c’était le chiffrier. Quelqu’un avait besoin de ce que le système ne donnait pas, alors il l’a bâti dans un classeur. Ça fonctionnait. Ça s’est partagé. Ça a pris des macros, des onglets cachés et une deuxième copie que personne ne réconciliait. Puis la personne qui le comprenait est partie.
C’est de la dette technique. Personne ne l’appelait ainsi, parce que personne ne voyait un classeur comme un logiciel. C’en était un : il faisait tourner le processus, il portait la logique, et il tombait en panne comme un logiciel, en silence et le jour où ça comptait.
L’IA générative met la même vitesse dans un nouvel outil, et la même dette vient avec. Une application générée en un après-midi et jamais conçue, c’est un chiffrier avec une page de connexion.
Quelle compétence manque quand on commence à bâtir avec l’IA ?
Écrire le code n’a jamais été la partie difficile, et l’IA en fait maintenant l’essentiel. Ce qui manque encore, c’est ce que les outils ne couvrent pas : savoir ce qu’est un logiciel, et où il vit une fois qu’il existe.
Un outil ne tourne jamais seul. Il lit des données qui appartiennent à quelqu’un, il vit dans un réseau qui a ses règles, et il sera touché par des gens qui ne l’ont pas écrit. Sécurité, architecture, maintenabilité : ce qu’on oublie quand on bâtit vite avec l’IA générative, exactement comme on l’oubliait quand on bâtissait dans Excel. Le virage tient en une ligne : de l’outil qu’on demande à l’outil qu’on conçoit.
Qu’est-ce qui cloche quand on bâtit un outil interne ?
- La construction est cadrée par rapport au produit qu’elle remplace, plutôt que par rapport au processus qu’elle sert.
- La vitesse de livraison devient la seule mesure, et la facture de maintenabilité arrive plus tard.
- Elle est bâtie pour l’équipe mais pas avec elle, alors personne à l’interne ne peut la modifier.
- Trois équipes règlent la même pièce manquante de trois façons différentes, parce que personne ne savait que les deux autres l’avaient aussi.
- Personne n’a demandé où elle allait vivre : ce qu’elle peut atteindre, de quoi elle dépend, qui la met à jour.
Comment développons-nous quelque chose qui reste maintenable ?
Cadrer sur le processus, une seule fois
Nous bâtissons ce dont le travail a besoin, souvent bien moins que la liste de fonctionnalités d’un produit et bien plus utile — en vérifiant d’abord si une autre équipe l’a déjà bâti.
Rapide, mais avec les points de contrôle
Une ingénierie accélérée par l’IA avec révision humaine, tests, vérification de sécurité et une norme de maintenabilité : la vitesse sans la dette.
Le transfert fait partie du livrable
Vos équipes peuvent l’exploiter, l’encadrer et la modifier. Si ce n’est pas le cas, le projet n’est pas terminé.
La pièce manquante est encore un chiffrier ?
Décrivez-nous le processus que le produit n’a jamais tout à fait couvert. Nous vous dirons franchement s’il s’agit de quelques semaines de construction, d’une configuration que personne n’a essayée, ou d’une chose qu’une autre équipe possède déjà.