Qu'est-ce qu'une AI software factory ?

Une AI software factory est un système qui industrialise la livraison logicielle. Un besoin décrit entre sous forme d'entrée normalisée, des agents IA réalisent le travail de tout le cycle de livraison dans un parcours contrôlé et instrumenté, et une application déployée en sort, possédée par l'organisation qui l'a commandée, chaque version restant rattachée à ce qui l'a produite.

S'il ne fallait retenir qu'une chose de ce guide : ce qui sépare deux factories n'est pas leur vitesse de production. C'est jusqu'où la chaîne tourne sans intervention humaine, et qui prononce la recette au bout.

Définition : les quatre termes qui portent le sens

Quatre parties de la phrase d'ouverture font le travail, et chacune exclut quelque chose.

Industrialise. Le résultat est reproductible au lieu de dépendre de la personne qui s'en est occupée. Même entrée, même parcours, mêmes contrôles, résultat comparable. Quelqu'un de compétent qui relance un modèle jusqu'à obtenir un résultat n'industrialise rien, aussi bon soit le résultat.

Tout le cycle de livraison. Pas la seule génération de code. Le cadrage, la spécification, le design, le développement, la qualité, les données, le déploiement et les changements qui suivent. Un système qui couvre une étape augmente un rôle. Une factory couvre le cycle.

Dans un parcours contrôlé et instrumenté. Tout ce qui part en production passe les mêmes portes, et la chaîne rend compte d'elle-même. Des contrôles contournables ne sont pas des contrôles, et une chaîne qu'on ne mesure pas ne s'améliore pas.

Une application déployée qui vous appartient. Le livrable est du logiciel de production, backend compris, dans votre dépôt, sur l'infrastructure de votre choix. Pas une maquette, pas une démo, pas une application qui ne tourne que sur le runtime de l'éditeur.

Glossaire : les termes employés dans ce guide, en langage courant

Exemple : une application interne suivie sur les six étapes, de la demande au quarantième changement

Prenons une application qui existe dans presque toutes les organisations : le suivi des demandes d'achat. Aujourd'hui elle vit dans un tableur, un fil d'e-mails, et une personne qui connaît les règles. Voici le même besoin passé dans une factory. C'est une illustration, pas un cas client.

Cadrage. Le responsable des opérations décrit le besoin : qui dépose une demande, qui valide au-dessus de quel seuil, quelles informations fournisseur doivent être jointes, et quel système porte la commande finale. Les contraintes sortent à ce moment : deux niveaux de validation, une politique d'achat interne, des données personnelles dans les contacts fournisseurs.

Spécifications. Le besoin devient une spécification écrite : quatre écrans, les règles de validation par montant et par entité, le modèle de données (demande, ligne, fournisseur, validation), qui a le droit de voir quoi, et la connexion au système de commande. Le responsable des opérations la lit et la valide. Rien n'est construit avant.

Développement. Les agents produisent l'application à partir de la spécification validée : écrans, logique métier, base de données, règles d'accès, intégration, tests. Le travail s'exécute dans un environnement isolé, sans accès au système de commande de production ni aux données fournisseurs réelles.

Recette. Le responsable des opérations ouvre l'application qui tourne et dépose une vraie demande sur des données de test. Le deuxième niveau de validation ne se déclenche pas au-dessus du seuil de délégation. Cette correction repart dans la spécification, pas dans une file de tickets.

Déploiement. L'application acceptée est déployée sur l'infrastructure choisie, connectée au SSO de l'entreprise, l'intégration pointant désormais vers le système réel. Selon l'organisation, le déploiement est tenu par l'équipe IT ou managé par la factory.

Évolutions. Six mois plus tard, une filiale a besoin d'un troisième niveau de validation. Le changement est vérifié contre la spécification validée, donc les règles qui fonctionnaient continuent de fonctionner, et les demandes déjà enregistrées sont reprises dans l'évolution du modèle de données au lieu d'être remises à zéro.

Deux choses dans cette séquence sont tout le sujet de ce guide. Le responsable des opérations a validé une spécification et accepté le résultat dans l'application qui tourne, sans lire une ligne de code. Et la sixième étape est le même cycle que la première, rejoué, sur des données qui existent désormais.

Composition : les cinq couches dont une factory est faite, de l'intention aux contrôles

1. L'intention

La couche qui transforme un besoin en entrée normalisée : un périmètre, des critères d'acceptation, un responsable désigné, un environnement cible, et la spécification qui les relie. Elle énonce ce que le logiciel doit faire, dans des termes que la personne qui en a besoin sait lire et valider.

C'est cette couche qui décide qui a le droit de mettre du travail sur la chaîne, et sous quelle forme. C'est aussi la moins souvent construite des cinq.

2. Le contexte

Ce que les agents ont le droit de lire et l'obligation de respecter : le code existant, le modèle de données, les systèmes de référence à intégrer, le design system, et les standards et politiques internes qui contraignent toute solution.

Le contexte est ce qui sépare une application qui s'insère dans votre organisation d'une application seulement correcte. Il s'accumule, se versionne et se réutilise, au lieu d'être redonné à la main à chaque demande.

3. Les agents et l'orchestration

Le spectre de rôles qui couvre le cycle, en général produit, design, analyse, développement, qualité, données et déploiement, avec un agent spécialisé par rôle. Autour d'eux, le harness qui donne à chaque agent ses instructions, ses actions autorisées et son contexte, et l'orchestration qui enchaîne les rôles et gère les passages de relais, les reprises et les échecs.

C'est l'orchestration qui rend le travail multi-agents reproductible au lieu de le laisser émerger, et c'est elle qui permet aux étapes de s'enchaîner sans relais humain entre elles.

4. L'exécution et l'infrastructure

Là où le travail se passe physiquement : un environnement isolé par unité de travail, le provisioning des ressources que l'application déclare (base de données, files, stockage objet), des environnements de prévisualisation où observer le comportement avant toute intégration, et le chemin de déploiement vers l'infrastructure cible.

L'isolation est une propriété de sécurité avant d'être un confort : la construction ne doit détenir aucun accès permanent aux systèmes de production ni aux données réelles.

5. Les contrôles

Tout ce qui décide si une production a le droit de partir : tests automatisés et non-régression, analyse de sécurité, gestion des secrets et politique de flux sortants, règles d'accès (SSO, RBAC), piste d'audit qui enregistre qui a validé quoi et quand, et observabilité qui remonte ce que fait réellement l'application déployée.

C'est la couche sur laquelle un responsable sécurité vous interrogera en premier, et celle qui décide si le volume produit est un actif ou un passif.

Processus : ce qui entre et ce qui sort à chacune des six étapes, et qui décide

Le cycle est le même à la première version et au quarantième changement. La différence est que les exécutions suivantes partent de quelque chose qui existe déjà et qui doit continuer de fonctionner.

Deux remarques sur la dernière ligne. Les évolutions ne sont pas une phase qui vient après le projet : c'est le même cycle, rejoué, et c'est là que se concentre l'essentiel du coût d'un logiciel interne sur sa durée de vie. Et c'est la seule étape qui doit composer avec des données déjà présentes, ce que la plupart des implémentations traitent le plus mal.

Propriétés : les quatre tests observables qui séparent une usine d'un pipeline

Les définitions publiées sur le marché convergent sur quatre propriétés. Ce sont elles qui permettent de tester si un système mérite le nom.

Une entrée normalisée. Le travail entre avec un périmètre, des critères d'acceptation, un responsable et un environnement cible. Si le travail entre sous forme de conversation, il n'y a pas de chaîne, seulement une conversation plus rapide.

Un parcours de contrôles unique. Tout ce qui part en production passe les mêmes portes, quelle qu'en soit l'origine, humaine ou agent. Un parcours qu'on contourne quand la date approche n'est pas un contrôle.

Une production mesurable. Le délai, le taux de défauts et le coût sont remontés par la chaîne elle-même plutôt qu'estimés après coup. C'est ce qui permet d'améliorer une factory au lieu de simplement lui faire confiance.

La rejouabilité. Toute version livrée peut être reconstituée à partir de ce qui l'a produite : ses entrées, sa spécification, les versions de modèles utilisées, les règles en vigueur à ce moment. C'est ce qui rend un audit possible après coup, au lieu d'en faire un exercice de mémoire.

Un point de structure complète la liste : une factory est une boucle, pas un tuyau à sens unique. Ce que l'application déployée remonte, en incidents, en usages et en défauts, revient en entrée du cycle suivant.

Frontières : les cinq catégories voisines avec lesquelles on la confond, et où chacune s'arrête

Chacune est légitime, et chacune s'arrête à un endroit précis.

Origine : pourquoi l'idée ne tient pas en 2004, tient dans la défense à partir de 2017, et devient possible en 2026

L'idée précède l'IA de vingt ans. Elle est publiée en 2004 par deux architectes de Microsoft, qui défendent une production logicielle sur des chaînes reproductibles plutôt qu'assemblée à force d'efforts individuels. Elle ne tient pas, pour une raison précise : la chaîne se nourrissait de modèles écrits dans un langage formel, chaque application devait encore être assemblée à la main à partir de composants, et la normalisation devait être conçue à l'avance. Une chaîne aussi coûteuse ne se rentabilise qu'en produisant beaucoup de logiciels presque identiques, ce que le logiciel interne d'une organisation n'est justement pas.

Des programmes de défense la reprennent à partir de 2017, avec un changement décisif. Ces organisations exploitaient elles-mêmes ce qu'elles livraient, donc l'usine portait les conséquences de sa propre production au lieu de livrer et de passer à autre chose.

Trois choses ont changé d'ici 2026, et elles se tiennent.

Le coût de produire une variante s'est effondré. Produire une application propre à une seule organisation n'a plus besoin d'être amorti sur beaucoup d'applications semblables. La chaîne peut produire une application unique qui tombe juste, ce qui lève la condamnation de 2004 au générique.

L'entrée n'a plus besoin d'être formelle. La chaîne de 2004 se nourrissait de modèles en langage formel, donc seuls des ingénieurs pouvaient y déposer du travail. Une spécification en langage courant suffit désormais à produire, ce qui change qui est en mesure d'alimenter la chaîne.

La normalisation s'est déplacée des composants vers les portes. Au lieu de contraindre à l'avance ce qu'on peut construire, en dessinant les pièces, une factory contrôle ce qui a le droit de sortir, aux portes. C'est ce qui rend la variété et le contrôle compatibles pour la première fois.

Ensemble, ces trois points signifient que la production n'est plus la contrainte. Ce qui pose la question à laquelle répond la section suivante : jusqu'où la chaîne tourne-t-elle seule, et à quels moments quelqu'un décide ?

Autonomie : ce qui tourne sans intervention humaine, et les deux décisions qui restent les vôtres

Dans la factory standard, l'humain est dans la boucle. Un ingénieur écrit la spécification, dans le vocabulaire du code. Des ingénieurs débloquent les agents entre les étapes. Un ingénieur lit le diff et décide si ça part. La chaîne est plus rapide, mais elle s'arrête à chaque étape en attendant quelqu'un, et son débit reste plafonné par la quantité de code dont vos ingénieurs peuvent répondre. Les mesures 2026 sur les temps de revue tombent exactement là.

Une factory autonome déplace l'humain aux bornes de la boucle. Les six étapes s'enchaînent sans relais humain : le cadrage produit la spécification, la spécification produit l'application, l'application est testée et vérifiée contre ce qui tourne déjà, et le déploiement suit. Personne ne pilote les agents, personne ne passe le relais d'un rôle au suivant.

Autonome ne veut pas dire que personne ne décide. Deux décisions restent humaines, et ce sont les deux qui comptent.

Ce qui entre. Le responsable métier valide la spécification, en langage courant, avant que quoi que ce soit ne soit construit.

Ce qui sort. La même personne recette le résultat dans l'application qui tourne, pas dans un diff.

C'est cette combinaison qui rend l'autonomie acceptable dans une organisation régulée. L'autonomie sans point de contrôle est la première crainte que les acheteurs nomment, et ils ont raison de la nommer. L'autonomie entre deux points de contrôle tenus par le métier est autre chose : le travail se fait seul, les décisions restent à leur place, et chaque version renvoie à une spécification que quelqu'un a validée.

Une dernière propriété fait tenir cela dans la durée : la spécification est conservée. Le marché commence à dire que la vraie surface de contrôle est la spécification, pas le diff. L'intuition est juste, la pratique ne suit pas encore. Dans les deux versions qui sortent aujourd'hui, la spécification est une entrée qui disparaît une fois le changement parti. Cela en fait un meilleur prompt, pas un contrat, et il ne reste rien contre quoi vérifier le changement suivant. Conservée, elle devient la référence contre laquelle le nouveau comportement est vérifié, la raison pour laquelle les données déjà présentes peuvent être reprises dans une évolution du modèle de données, et l'artefact qui fait de la piste d'audit un produit dérivé de la façon dont le logiciel a été fabriqué.

Checklist : si une factory répond à votre situation, et les six questions à poser ensuite

Elle répond à votre situation si

• Le processus est durable et critique pour l'activité, et il comptera encore dans trois ans.
• Il tourne aujourd'hui sur un tableur, un fil d'e-mails, ou une application que plus personne ne maintient.
• Vous n'avez pas d'équipe de delivery à y mettre, et ça ne passera jamais devant les projets critiques dans le backlog.
• Le logiciel touche des données sensibles, ou doit passer une revue sécurité, conformité ou achat.
• Des équipes métier ont déjà construit des applications avec de l'IA, et personne ne sait dire ce qu'elles font ni où elles tournent.
• Le besoin va continuer de changer. D'autres versions suivront la première.

Elle n'y répond pas si

• Ce qu'il vous faut est une maquette jetable, à valider puis à jeter.
• Ce que vous cherchez est à rendre vos propres développeurs plus rapides sur votre propre produit. C'est un assistant de code.
• Un logiciel du marché couvre déjà correctement le besoin.
• Personne ne portera le besoin côté métier. Une factory a besoin de quelqu'un capable de valider une spécification et d'accepter le résultat.

Les six questions à poser à toute option, y compris à un projet interne

1. Qui accepte le travail ? Si seul un ingénieur qui lit le code peut accepter, votre capacité de livraison est votre capacité de revue.
2. Que valide le responsable métier, et sait-il le lire ? Une spécification en langage courant est un contrat. Un ticket n'en est pas un.
3. La spécification est-elle conservée après la mise en production, et le changement suivant est-il vérifié contre elle ?
4. Que deviennent les données déjà présentes dans l'application quand le modèle de données change ?
5. La construction peut-elle atteindre vos systèmes de production ou vos données réelles par défaut ? La bonne réponse est qu'elle ne le peut pas par construction, et non qu'on l'a désactivé par configuration.
6. Où vit le code à la fin, et de quoi a-t-il besoin pour continuer à tourner ?

Livrable : ce que vous tenez quand la factory a terminé

Le livrable est l'application entière, backend compris : les écrans que les gens utilisent, la logique derrière, la base de données, les règles d'accès et les intégrations avec les systèmes que vous exploitez déjà.

Elle arrive sous forme de code standard dans votre propre dépôt Git, déployée sur l'infrastructure de votre choix, hébergée, sur votre cloud ou en on-premise. Vous pouvez la lire, la modifier et la garder sans la plateforme qui l'a produite. La propriété est ce qui sépare une usine qui vous fournit d'une plateforme dont vous dépendez.

Questions : les cinq qui reviennent le plus, et leurs réponses courtes

Est-ce que ça remplace les développeurs ? Non, et ce n'est pas là que ça se joue. Une factory produit le logiciel de bout en bout, donc la demande de logiciels internes cesse d'atterrir sur vos développeurs. Ils restent sur les projets critiques, ceux qui portent votre produit et votre avantage, au lieu de se disperser sur le énième circuit de validation. Dans une organisation qui n'a pas de développeurs à y mettre, la factory livre ce qui serait resté dans le backlog.

Faut-il une équipe technique pour en utiliser une ? Non. La personne qui porte le besoin peut aller jusqu'au bout : elle décrit, valide la spécification, recette le résultat dans l'application, et le déploiement peut être managé. C'est le plancher bas. Le plafond, lui, reste haut : si vous avez une équipe technique, elle garde la main partout où elle le veut, sur l'infrastructure cible, les systèmes connectés, les règles d'accès, et sur le code lui-même, puisqu'il est dans votre dépôt.

Quelle différence avec « décrire son application en langage naturel » ? L'entrée en langage naturel est désormais commune à toutes les catégories, donc à elle seule elle ne dit rien. La différence est dans ce qui vient après : est-ce que tout le cycle est couvert, est-ce que les contrôles tiennent, est-ce que le résultat est à vous et maintenable.

En combien de temps la première version, et est-ce le bon critère ? La vitesse jusqu'à une première version est devenue le critère le moins discriminant, parce que toutes les catégories y sont rapides. Le coût est dans les changements qui suivent.

Que se passe-t-il si on arrête ? Vous gardez l'application et les spécifications. Du code standard, dans votre dépôt, sur l'infrastructure que vous avez choisie. Cela continue de tourner sans la factory qui l'a produit.

Maleus : une factory autonome, et ce que ça change par rapport à la définition standard

Maleus est une AI software factory autonome pour les logiciels internes. Une équipe de spécialistes IA couvre tout le cycle de livraison, un par rôle : produit, design, analyse, développement, qualité, données et déploiement. Les six étapes s'enchaînent sans relais humain, et les deux décisions qui comptent restent à la personne qui a besoin du logiciel.

La construction est déterministe et gouvernée par la spécification validée, donc le comportement tient à mesure que le logiciel évolue. Chaque construction s'exécute de façon isolée, sans accès permanent à vos systèmes de production, et chaque action est enregistrée. Prête pour SOC 2 et compatible ISO 27001.