Plus tôt cette année, notre équipe chez 8090 a démantelé le moteur de facturation d'une grande entité. C'était 18 millions de lignes de COBOL et d'Assembleur qui s'accumulaient depuis avant même la naissance de certains de nos ingénieurs. Personne ne le comprenait plus entièrement, mais en utilisant notre Software Factory, nous l'avons rétro-ingénié en plus de 100 000 règles en anglais simple en 40 jours. En terminant ce travail, j'ai réalisé pourquoi l'expression « software factory » était soudainement utilisée par tout le monde aussi.
Le concept est réapproprié parce qu'il implique un certain niveau de fiabilité industrielle que les entreprises veulent mais n'obtiennent pas. Les software factories ont cinquante ans d'histoire derrière elles, et leur caractéristique singulière est quelque chose dont les entreprises ont plus besoin que jamais : un système de production qui garantit le résultat. Cela contraste avec une frustration croissante face à un ensemble tentaculaire d'outils qui responsabilisent les individus mais rendent les systèmes entiers plus chaotiques.
Le terme est plus ancien que la plupart des gens ne le pensent
Hitachi a ouvert « Software Works » en 1969 comme une véritable usine : un bâtiment où les logiciels étaient produits sous contrôle qualité statistique, avec des taux de défauts mesurés par millier de lignes de code, des processus standardisés et une équipe de direction responsable de la qualité des résultats. Toshiba, NEC et Fujitsu ont suivi, et dans les années 1970 et 1980, ces software factories japonaises ont livré certains des codes les plus fiables jamais écrits. Les systèmes qu'elles produisaient ont fait fonctionner la banque, le rail et les infrastructures énergétiques pendant des décennies.
En 2004, deux architectes de Microsoft ont publié un livre intitulé « Software Factories » arguant que les logiciels devraient être construits comme les voitures : à partir de composants éprouvés, sur des chaînes de production reproductibles, avec des variations contrôlées par une conception en amont plutôt que réparées par des actes héroïques en aval. L'US Air Force exploite aujourd'hui des software factories. Kessel Run construit et exploite des logiciels de mission pour le Département de la Défense, et quand ces logiciels tombent en panne, ils en sont responsables.
Sur soixante ans, une chose est restée constante jusqu'à cette vague d'IA. Une usine n'a jamais été un outil ou une astuce de productivité, aussi bon soit-il. Une usine était un système de production qui prenait des intrants, produisait des biens finis et garantissait la qualité de ces biens. Autrement dit, Ford ne vous a jamais vendu une clé, des pièces en vous souhaitant bonne chance. Ford vous a vendu une voiture, et si la voiture tombait en panne, Ford la rappelait, parce que c'était leur usine qui l'avait produite.
C'est la norme, et je soutiens que les software factories modernes doivent aussi s'y conformer.
Les cinq tests
Une software factory doit réussir cinq tests. Manquez-en un seul et vous avez autre chose. Cette autre chose est très probablement un outil de développeur, qui peut être utile, mais qui est un produit différent avec une obligation différente.
Test un : une usine part de l'intention commerciale. L'intrant d'une usine est ce dont l'entreprise a besoin, exprimé dans le langage de l'entreprise : exigences, règles, contraintes réglementaires, résultats souhaités. Si l'intrant est, à la place, un ticket Jira écrit par un ingénieur pour un autre ingénieur, vous regardez un outil puissant boulonné sur un processus existant. Tout l'intérêt d'une usine est que le client décrit le produit et que l'usine se charge de la production.
Test deux : une usine maintient la cohérence sous un changement continu. C'est le test le plus difficile, et c'est celui dont presque personne sur le marché des outils d'IA ne parle, parce que leurs produits empirent la situation.
Écrire du nouveau code n'a jamais été le goulot d'étranglement dans les logiciels d'entreprise. Le goulot d'étranglement, c'est qu'un système réel est modifié chaque semaine par des dizaines de personnes. Chaque modification est une occasion pour le système de se désagréger. Les exigences s'éloignent de la documentation. La documentation s'éloigne du code. Le code s'éloigne des tests. Laissez cette dérive s'accumuler pendant vingt ans et vous obtenez le moteur de facturation que j'ai décrit au début : 18 millions de lignes que personne ne comprend dans leur intégralité, un contrat de maintenance avec des fournisseurs qui augmentent de 5 à 8 % par an et une organisation qui ne peut plus modifier ses propres logiciels sans crainte.
La réalité est que la génération de code accélère la dérive. Si vos agents produisent dix fois plus de code par rapport à des spécifications qui ne sont pas maintenues synchronisées, vous induisez une dérive à une vitesse sans précédent. Le problème des 18 millions de lignes a mis quarante ans à se construire à la main, mais des flottes d'agents sans gouvernance le construiront en quelques années.
Une software factory fonctionnelle maintient l'intention, la spécification, le code, les tests et la production synchronisés comme un seul objet gouverné. Modifiez l'exigence et le code change. Corrigez le code à chaud et l'exigence se met à jour. Demandez à un fournisseur de vous montrer cette boucle fermée, en direct sur un système réel. S'il ne peut pas, il vend de la génération de code. Et bien qu'utile, c'est une chose différente.
Test trois : une usine fonctionne indépendamment de toute personne spécifique. Un outil n'est aussi bon que la personne qui le tient. Donnez le même agent de codage à deux ingénieurs et vous obtiendrez des résultats radicalement différents selon qui écrit les prompts, qui examine les diffs et qui attrape les erreurs. Cette variance est acceptable dans un outil. Elle est disqualifiante dans un système de production. Une usine doit produire à une vitesse et une qualité prévisibles, indépendamment de qui est de service, ce qui est exactement ce que les contrôles statistiques de Hitachi étaient conçus pour garantir : la qualité comme une propriété de la chaîne, pas de l'opérateur.
La façon dont une usine y parvient est que la connaissance se capitalise dans le système plutôt que dans les individus. Quand une personne rejoint, l'usine lui transmet tout ce qu'elle a déjà appris. Quand une personne part, rien ne sort par la porte. La plupart des logiciels d'entreprise échouent à ce test de manière catastrophique. La raison pour laquelle un moteur de facturation devient illisible n'est pas le mauvais code. C'est que la compréhension du code vit dans les personnes, et au fil des années, les personnes changent. Si leur connaissance n'est jamais capturée par un système, le système deviendra lentement une boîte noire.
Pour être clair, cela ne signifie pas que les gens ne comptent pas ou qu'une usine n'exige pas de responsabilité. Une usine a toujours quelqu'un de spécifique qui répond du résultat. Elle ne dépend simplement jamais d'aucun d'entre eux comme étant irremplaçable. Un système qui a besoin d'un héros pour fonctionner n'a ni responsabilité ni usine. Il a un héros, et les héros finissent toujours par trouver de nouvelles aventures.
Test quatre : chaque unité de résultat est traçable. Dans une vraie usine, chaque pièce a un « numéro de lot ». Quand quelque chose échoue, vous remontez la chaîne de production jusqu'au lot, à la machine et à l'équipe. Les industries réglementées exigent exactement cela des logiciels, et c'est pourquoi elles ont été les plus lentes à adopter les outils de codage IA. « C'est le modèle qui l'a écrit » n'est pas une réponse qu'un auditeur accepte. Une software factory produit la piste d'audit comme un sous-produit de la production elle-même : cette règle existe à cause de cette exigence, approuvée par cette personne, implémentée dans cette modification, vérifiée par ce test, déployée à cette heure. La provenance doit être intégrée dans la chaîne de production, ce qui signifie que la documentation écrite après coup ne compte pas.
Test cinq : quelqu'un est responsable du produit fini. C'est le test qui sépare une software factory d'un outil de développeur, car c'est celui que la plupart des fournisseurs d'outils ne sont pas prêts à satisfaire.
Une usine livre un produit dont elle est responsable. Quand le moteur de facturation calcule mal une réclamation, quand le système de trading produit un mauvais chiffre, quand la validation de fabrication approuve une mauvaise pièce, quelqu'un de spécifique répond, répare et assume le coût. J'ai maintenant lu beaucoup de contrats d'outils d'IA et les sections sur la propriété intellectuelle s'étendent sur des pages, mais la section sur la responsabilité est généralement une phrase, et cette phrase dit que le résultat est fourni en l'état et que la vérification est votre problème. C'est totalement disqualifiant pour une usine.
L'un de nos clients, un assureur maladie coté en bourse, a transformé ses règles de traitement des réclamations en un pré-filtre déterministe et a réduit de plus de 80 % les réclamations acheminées vers un fournisseur payé à la prestation, évitant ainsi plus de 20 millions de dollars sur quatre ans. Des chiffres comme ceux-ci n'arrivent que lorsque la partie qui effectue le travail est responsable du résultat.
Ce qui n'est pas une usine
Appliquez les tests et beaucoup de ceux qui se disent une usine sont, en réalité, autre chose.
Les agents de codage, aussi bons soient-ils, sont des outils. Ils prennent des tâches d'ingénierie en entrée, produisent du code en sortie, et transfèrent toute la vérification et la responsabilité aux ingénieurs du client. Appeler une flotte d'entre eux une usine ne change rien à cela.
Les tableaux de bord d'orchestration d'agents sont des outils de supervision. Ils facilitent l'observation du travail des agents.
Les benchmarks sont des outils de mesure pour les outils. Un score élevé vous indique qu'un outil est bon pour les tâches benchmarkées. Il ne peut pas vous dire si votre système reste cohérent après deux ans de changements continus par des équipes mixtes d'humains et d'agents.
Pourquoi la définition est importante maintenant
Le coût de production des logiciels s'effondre. Et quand les coûts de production s'effondrent, la valeur migre vers celui qui peut garantir le résultat. Cela s'est produit dans tous les processus d'industrialisation avant celui-ci et cela se reproduira maintenant avec l'IA.
Les startups qui s'emparent du mot « usine » comprennent cela instinctivement. Mais beaucoup cherchent à obtenir la crédibilité de la production industrielle sans accepter l'obligation qui a créé cette crédibilité en premier lieu.
Alors ignorez les démos et les benchmarks, et posez à chaque software factory une question : quand le système tombe en panne en production, qui prend l'appel ?
Dans le cas d'une software factory, la réponse doit être « nous ».
