Pourquoi la software factory devient stratégique à l’ère de l’IA

Une software factory organise le passage du besoin au logiciel livré

Réussir une opération et savoir la reproduire sont 2 choses différentes. Dans le développement logiciel, industrialiser consiste à définir les étapes, les informations nécessaires et les vérifications qui rendent le travail reproductible. Le résultat reste un logiciel adapté à votre activité.

Une software factory réunit cette méthode et les outils qui l’exécutent. Avec l’IA, elle fait intervenir des agents, des logiciels capables de lire un projet, de modifier son code et de lancer des vérifications. L’agent s’appuie sur un modèle, le moteur d’IA qui produit ses réponses, et agit avec les outils et les permissions disponibles.

Vous pouvez regrouper les consignes et les outils nécessaires dans un harness, l’environnement qui fait fonctionner l’agent sur votre projet. Pour le paiement, il peut lui donner accès aux applications concernées et aux moyens de tester le parcours. Les 10 pièces du harness détaillées dans le retour sur l’application mobile en montrent un exemple concret.

Vous pouvez voir une partie de la méthode dans les skills : des instructions réutilisables qui expliquent à un agent comment accomplir une tâche. Un skill de préparation de ticket peut, par exemple, lui demander de repérer les informations manquantes avant de proposer un plan.

Le ticket est la fiche de travail qui décrit une modification attendue. Une bonne instruction précise aussi ce que l’agent doit produire et quand il doit solliciter un humain. Vous évitez ainsi de reconstruire toutes les consignes au début de chaque demande.

Dans ma pratique, j’utilise déjà l’IA pour 4 ensembles de tâches :

• Préparer les tickets, puis aider à les relire, les classer et les prioriser.
• Produire les spécifications, le plan de réalisation et le code correspondant.
• Exécuter les tests et préparer les modifications pour leur relecture.
• Rechercher l’origine d’un bug à partir des journaux techniques, les traces des actions et des erreurs de l’application, consultés dans Grafana, l’outil de suivi des applications.

Votre usine logicielle comprend également des automatismes classiques, comme l’installation d’une version, les sauvegardes de la base de données ou les alertes en cas d’incident serveur. Une sauvegarde planifiée peut s’exécuter automatiquement sans faire appel à l’IA. L’intérêt est de relier ces opérations à la fabrication et au suivi du logiciel.

La définition publiée par Vercel décrit elle aussi un système reproductible dans lequel les travaux des agents passent par des contrôles et une revue. Les humains décident du travail utile et de l’autorité accordée au système.

La méthode de la software factory devient un actif stratégique

Vous pouvez donner accès au même modèle d’IA à 2 prestataires sans obtenir le même résultat. Celui qui connaît vos règles et sait faire vérifier le travail dispose d’informations que l’abonnement au modèle ne fournit pas. La différence se voit quand la demande dépasse un écran isolé.

Pour votre tunnel de paiement, la méthode doit apporter 3 éléments à l’agent :

• Le résultat attendu et les cas qui permettraient de constater une erreur.
• Les applications concernées, leurs liens et les règles à respecter dans chacune.
• Les contrôles à passer et la personne à solliciter quand une décision manque.

Un framework, c’est ici le cadre de travail qui assemble ces instructions et ces contrôles. Dans cet article, « méthode propriétaire » désigne le cadre propre au prestataire. Les droits sur ses différents outils et sur le logiciel livré restent à préciser séparément.

Une erreur découverte sur un projet peut devenir une vérification réutilisée sur les suivants, lorsque le contexte s’y prête. Votre prestataire enrichit ainsi sa façon de travailler au fil des problèmes rencontrés et des corrections qu’il sait réutiliser.

Vous profitez alors d’un savoir qui s’accumule au lieu de dépendre de ce que le développeur se rappelle pendant sa session. Un test ajouté doit rester disponible. Une règle clarifiée doit se retrouver dans le prochain ticket concerné. La valeur se matérialise dans ces éléments conservés.

Ma conviction est que les modèles frontières, les modèles d’IA les plus avancés, vont devenir une commodité. Tout le monde peut accéder aux mêmes modèles : leur disponibilité devient un acquis du marché.

Une méthode propriétaire, développée puis améliorée pendant des mois, voire des années, est unique. Elle porte les choix et les apprentissages accumulés sur le terrain. Vous pouvez acheter l’accès au même modèle que votre prestataire, mais cet abonnement ne vous donne pas sa méthode.

Votre enjeu, quand vous financez des développements, est de bénéficier de cette capacité sans perdre la maîtrise du logiciel. Les outils internes du prestataire peuvent lui appartenir ; le code livré et les moyens de le reprendre doivent être explicitement prévus dans votre accord.

Une software factory coordonne les changements entre vos applications

Reprenons le tunnel de paiement comme exemple de périmètre à coordonner. Le parcours touche plusieurs parties du logiciel, dont certaines peuvent avoir leur propre dépôt, l’espace qui conserve leur code et son historique. Un changement dans un dépôt peut exiger une adaptation dans un autre.

Vous ne pouvez pas conclure que le parcours fonctionne parce que chacun de ses écrans s’affiche. Si le service de paiement confirme l’achat mais que l’administration le considère encore en attente, vos équipes devront rechercher l’origine de l’écart. C’est un cas à tester avant de livrer.

La méthode doit donc préparer les changements ensemble, même quand leur réalisation est répartie. Elle précise quels éléments dépendent des autres et ce qu’un lot doit permettre de vérifier. Le développeur peut ensuite relire un changement limité sans perdre de vue le parcours complet.

Vous pouvez, par exemple, demander une progression en 3 lots fonctionnels, à adapter aux règles de votre activité :

1. 1Un achat réussi sur une offre déterminée, depuis la page de vente jusqu’à sa visibilité dans l’administration.
2. 2Le traitement d’un paiement refusé ou interrompu, avec un état compréhensible pour le client.
3. 3Le comportement en cas de confirmation reçue plusieurs fois, pour éviter les actions répétées.

Chaque lot doit être vérifiable ; la mise en service attend les cas nécessaires à un paiement fiable. Vous n’avez aucun intérêt à ouvrir un parcours incomplet à vos clients pour pouvoir annoncer une livraison rapide. Le découpage sert à obtenir des retours pendant la construction.

Sur certains tickets complexes touchant plusieurs dépôts interdépendants, je suis passé de 1 à 3 semaines à 1 à 3 heures. Je compare ici mon propre travail avant et aujourd’hui, du cadrage du ticket à la livraison en production.

La fourchette annoncée est un retour d’expérience personnel, sans protocole de mesure contrôlé ni garantie pour votre projet. Elle n’est pas le résultat mesuré du tunnel de paiement présenté ici. Pour comparer des délais, vérifiez toujours ce qu’ils incluent et ce qui était déjà en place.

Le décryptage sur le développement d’une application mobile avec l’IA apporte un autre retour de terrain. Le périmètre diffère, mais la même question revient : quelles informations et quelles vérifications rendent l’accélération utilisable ?

Les contrôles humains font partie de la software factory

Prenons une idée évoquée pendant une réunion. La capture automatique peut en tirer un pré-ticket, une première fiche à compléter. Elle n’en fait pas une commande de développement : quelqu’un doit encore préciser le besoin et décider de sa priorité.

Je cadre le besoin avant de créer le ticket. L’IA prépare ensuite la spécification, le document qui décrit le comportement attendu, que je relis avant le développement. Le décryptage sur le spec-driven development détaille ce qu’il faut juger dans ce document. Une ambiguïté métier doit trouver une réponse à ce stade.

Reste à savoir ce que couvrent les tests. Les tests unitaires vérifient une petite partie du code isolément. Les tests fonctionnels vérifient un comportement attendu, par exemple la possibilité d’acheter une offre et d’en retrouver la confirmation.

Les contrôles de sécurité complètent ces vérifications sur les risques qu’ils savent détecter. Aucun résultat vert ne prouve que tous les problèmes possibles ont disparu. Le responsable technique doit examiner les tests exécutés et leurs limites, puis relier ces résultats au besoin initial.

Votre point de contrôle humain doit disposer d’éléments concrets : une proposition de modification du code et les résultats de ses vérifications. Je relis ces éléments avant que la chaîne poursuive la livraison en préproduction, l’environnement d’essai qui précède la mise en service.

La production est l’environnement utilisé par vos clients ou vos équipes. Le passage en préproduction ne signifie donc pas que la fonctionnalité leur est ouverte. Faites préciser qui décide de cette ouverture et quels contrôles restent à réaliser, selon les engagements de votre projet.

Vous gardez aussi un rôle dans la recette métier, la vérification que le résultat correspond au besoin commandé. L’IA peut exécuter un scénario connu. Elle ne peut pas décider à votre place si une règle commerciale mal formulée correspond réellement à votre activité.

Les progrès des modèles IA permettent d’enrichir la méthode

Une méthode construite aujourd’hui sera-t-elle dépassée au prochain changement de modèle ? Une partie des outils devra effectivement évoluer. Les règles de votre métier et les critères qui permettent d’accepter une livraison restent pourtant utiles quand le moteur qui exécute les tâches change.

Le découpage du travail en fournit un exemple concret. Je constate que les modèles actuels m’aident mieux à préparer des tâches livrables par lots incrémentaux, c’est-à-dire des ajouts successifs et vérifiables. La méthode peut intégrer cette capacité tout en conservant la relecture du découpage.

Votre prestataire doit donc savoir essayer une capacité nouvelle sur une tâche réelle et juger si elle améliore le résultat. Il peut ensuite adapter ses instructions et ses contrôles. Un changement de modèle demande une évaluation ; conserver le même cadre ne rend pas les modèles interchangeables sans vérification.

Je fais évoluer cette méthode en continu. Avec les connaissances que j’ai aujourd’hui, j’estime qu’il me faudrait 1 à 2 semaines pour la reconstruire, selon la complexité. Cette estimation ne mesure ni l’effort d’apprentissage passé ni le délai d’installation dans votre entreprise.

Pour démarrer, choisissez un parcours suffisamment limité pour observer le résultat, puis examinez ce qui peut servir au prochain lot. Faites chiffrer les adaptations nécessaires à votre projet. L’investissement devient plus facile à discuter quand vous voyez ce qui est réutilisable.

Je prévois aussi d’ajouter des preuves vidéo : enregistrer les parcours de tests fonctionnels pour accélérer leur revue. Cette fonction n’est pas encore en place. L’intérêt est de rendre le comportement plus rapide à examiner, en complément des résultats de tests.

Vous pouvez appliquer le même raisonnement à toute nouvelle automatisation proposée : quel travail prépare-t-elle, quel résultat rend-elle visible et quelle décision reste humaine ? Le nombre d’agents utilisés donne peu d’informations si personne ne sait expliquer le chemin suivi par une demande.

Comment évaluer la software factory de votre prestataire

Vous n’avez pas besoin de connaître tous les outils pour juger la méthode. Demandez à votre prestataire de suivre une fonctionnalité de votre projet, depuis la première formulation du besoin jusqu’à son utilisation. Vous verrez alors les informations qu’il demande et les preuves qu’il produit.

Pour préparer votre prochaine discussion, suivez ces 5 étapes dans l’ordre :

1. 1Choisissez une fonctionnalité réelle. Prenez une évolution qui relie plusieurs parties de votre logiciel. Décrivez le résultat attendu pour l’utilisateur et les cas qui vous empêcheraient d’accepter la livraison.
2. 2Demandez le parcours complet d’un ticket. Faites préciser ce que l’IA prépare, ce qu’elle exécute et ce qu’un humain décide. Repérez les attentes entre les étapes et le point où s’arrête l’automatisation.
3. 3Examinez un résultat vérifié. Demandez une démonstration du parcours et les résultats des tests associés à la version livrée. Faites expliquer ce qui reste à vérifier et qui s’en charge avant la production.
4. 4Comparez le délai jusqu’à l’usage réel. Incluez le cadrage et les corrections dans la discussion, puis les validations et la mise en service. Un temps de génération du code ne répond pas à la question du délai de livraison.
5. 5Vérifiez ce que vous récupérez. Faites préciser les accès, le code et la documentation remis, ainsi que la procédure pour installer une nouvelle version. Demandez ce qu’un autre développeur pourrait faire sans les outils internes du prestataire.

Votre décision peut alors porter sur la capacité à livrer et à faire évoluer votre logiciel. La software factory devient stratégique quand elle transforme les progrès de l’IA en une méthode réutilisable, dont votre prestataire sait expliquer les décisions et montrer les résultats.

Questions fréquentes sur la software factory et l’IA

Sources et documentation

La méthode et les estimations présentées ici viennent de ma pratique. Le tunnel de paiement illustre un périmètre à coordonner ; le découpage en lots et les cas de test sont des exemples pédagogiques. La référence suivante a été consultée le 17 septembre 2026.

• Vercel, What is an AI software factory, 14 septembre 2026 ↗