Software factory et agentic coding : digitaliser vos processus non critiques sans passer par le SaaS

Le point de bascule que la plupart des dirigeants n’ont pas encore intégré

Pendant vingt ans, la question de la digitalisation d’un processus métier se résumait à un arbitrage : acheter un logiciel en ligne (rapide, mais générique, récurrent, rarement adapté à vos particularités) ou construire en interne (sur mesure, mais lent, cher, réservé aux besoins qui justifient une équipe de développement)

Pour une PME ou une ETI, le calcul penchait presque toujours du même côté. Construire un petit outil interne, un suivi de conformité fournisseurs, un tableau de bord de production, un formulaire de collecte structuré, coûtait plusieurs dizaines de jours-homme. Alors on empilait les abonnements, on bricolait des tableurs partagés, ou on ne digitalisait tout simplement pas. La « dette de tableurs » d’une ETI de 300 personnes est une réalité que tout dirigeant connaît

En 2026, cet arbitrage a bougé. Pas parce que l’IA « écrit du code », ça, on le savait depuis GitHub Copilot en 2022. Mais parce qu’on est passé de l’autocomplétion à l’agentic coding : un agent qui prend une intention exprimée en langage naturel et produit un résultat de bout en bout. Il lit le dépôt, écrit le code, lance les tests, corrige ses propres erreurs et ouvre une pull request. Les modèles résolvent aujourd’hui une large majorité des problèmes de code standard là où ils en résolvaient une poignée deux ans plus tôt

La conséquence stratégique est simple : le coût de production d’un outil métier simple s’est effondré. Et quand un coût s’effondre, ce ne sont pas seulement les projets existants qui deviennent moins chers, c’est toute une catégorie de besoins jusqu’ici non rentables qui devient adressable

C’est exactement là que se situe l’opportunité pour les PME et ETI : non pas remplacer votre SI critique, mais internaliser la digitalisation de vos processus non critiques, au plus près des métiers, ceux qu’on n’a jamais eu les moyens de traiter

À ne pas confondre avec la question « qu’est-ce que l’IA agentique ». Si le concept d’agent autonome ne vous est pas familier, commencez par notre guide de l’IA agentique en entreprise. Cet article suppose le concept acquis et traite de sa conséquence économique : l’usine logicielle

L’ERP et le CRM restent la colonne vertébrale, et ce n’est pas le sujet

Il faut lever tout de suite un malentendu. L’usine logicielle ne vient pas remplacer votre ERP, votre CRM, votre SIRH ou votre logiciel de paie. Ces systèmes portent les processus structurants et souvent critiques de l’entreprise : la comptabilité, les ventes, les stocks, la production, les salaires. Ils sont éprouvés, maintenus, conformes. On n’y touche pas à la légère, et surtout pas avec un agent

Le problème n’a jamais été là. Le problème, ce sont les trous que ces logiciels laissent :

• les processus trop spécifiques à votre métier pour qu’un éditeur les couvre un jour
• la glu entre deux systèmes : réconcilier deux exports, un connecteur qui n’existe pas, un tableau de bord qui croise trois sources
• les besoins d’une seule équipe ou d’un seul site, que personne ne financera jamais dans une montée de version de l’ERP
• tout ce qui vit aujourd’hui dans des tableurs, des e-mails et des habitudes non écrites

Chaque personnalisation d’un ERP coûte cher et rigidifie l’outil : plus vous ajoutez de développements spécifiques dans le progiciel, plus ses montées de version deviennent lourdes et risquées. L’usine logicielle propose l’inverse : construire ces outils spécifiques à côté du progiciel, sans l’alourdir, en les gardant simples, jetables et remplaçables

La règle de partage est nette : ce qui est structurant et critique reste dans l’ERP, le CRM ou un logiciel en ligne dédié. Ce qui est spécifique et non critique passe par l’usine logicielle. C’est cette seconde catégorie, longtemps ignorée faute de moyens, qui devient soudain accessible

Ce qu’est réellement une usine logicielle, et ce qu’elle n’est pas

Le terme d’usine fait image, et l’image est juste : une usine, ce sont des machines qui fabriquent des machines. Une usine logicielle à l’ère de l’IA, ce sont des agents qui produisent du logiciel, orchestrés par des humains

Attention au contresens. Une usine logicielle n’est pas :

• un outil no-code ou low-code de plus (le résultat est du vrai code, versionné, testé, déployé, dont vous êtes propriétaire)
• du « vibe coding », c’est-à-dire demander une fonctionnalité et accepter le résultat sans le lire. Le vibe coding produit des prototypes jetables, il est dangereux en production
• une promesse de se passer d’ingénieurs

Une usine logicielle est une chaîne de production disciplinée. Sa mécanique repose sur une répartition de l’effort contre-intuitive : l’essentiel du temps passe dans le cadrage du contexte en amont et dans la revue-validation en aval, la production de code elle-même, celle que l’agent prend en charge, n’en représente qu’une part minoritaire

C’est le point le plus important de tout l’article. Dans une usine logicielle, écrire le code n’est plus le travail, c’est la partie la plus courte. Le travail, c’est cadrer (des spécifications structurées, des règles métier explicites, une architecture documentée) et valider (relire, tester, sécuriser). L’humain ne code plus : il structure le contexte et signe les résultats. Le développeur devient une sorte de chef d’orchestre qui coordonne la production plutôt qu’un exécutant

La métaphore que je trouve la plus parlante pour un dirigeant est celle de l’atterrissage. Les instruments de l’avion sont autonomes, mais le pilote reste aux commandes et valide à chaque phase. À chaque étape du cycle, trois temps s’enchaînent : l’humain définit l’intention (objectifs, critères de succès), l’agent exécute le livrable, l’humain valide et signe

Retenez cette boucle. C’est le cœur du modèle, et c’est ce qui sépare une usine sérieuse d’un générateur de dette technique

Pourquoi viser les processus non critiques d’abord

« Non critique » n’est pas un aveu de timidité. C’est un critère de sélection précis, et c’est la bonne porte d’entrée

Un processus non critique, c’est un processus dont la défaillance n’engage ni la sécurité, ni la conformité réglementaire, ni la continuité d’activité. Si l’outil tombe une matinée, personne ne perd de données sensibles, aucun client n’est bloqué, aucun régulateur ne s’en mêle. On répare et on continue

Concrètement, dans une PME ou une ETI, cette catégorie est immense :

• Suivi et reporting internes : tableaux de bord d’activité, consolidation d’indicateurs, suivi de plan d’action
• Outils d’équipe : gestion de demandes internes, intégration d’un nouveau collaborateur, réservation de ressources, suivi de conformité fournisseurs
• Automatisations bureautiques : extraction de données depuis des PDF, pré-remplissage de documents, notifications de relance
• Collecte structurée : formulaires métiers qui remplacent un échange d’e-mails et de tableurs

Ces besoins ont trois points communs : ils sont spécifiques (aucun logiciel du marché ne colle exactement), individuellement peu rentables à développer à l’ancienne, et collectivement énormes en gain de temps cumulé

Pourquoi commencer là, plutôt que par un sujet à fort enjeu ? Pour trois raisons :

1. Vous apprenez à gouverner la production agentique avec un risque maîtrisé. Les garde-fous (revue, sécurité, périmètre) s’installent à froid, pas sous la pression d’un système critique
2. Le retour est lisible et rapide. Un processus chronophage transformé en outil, c’est un gain de temps mesurable en semaines
3. Vous construisez la capacité avant d’en avoir besoin ailleurs. Le jour où un sujet sensible se présentera, l’usine, les garde-fous et la culture seront déjà là

C’est une méthode d’adoption, pas un plafond d’ambition

Centraliser ou décentraliser : deux modèles pour couvrir les besoins

Le projet est bien de digitaliser de manière décentralisée. Mais on n’y arrive pas d’un coup. Il existe deux modèles, et ils forment un continuum : une PME ou une ETI passe souvent de l’un à l’autre en gagnant en maturité

Modèle A : l’usine centrale à haut débit (centralisée)

Une petite équipe centrale, une à deux personnes augmentées par l’IA, produit vite des outils pour tous les métiers. L’idée : ces deux profils couvrent le périmètre qui aurait mobilisé une équipe entière hier, parce que le cycle de production est industrialisé

Ce modèle n’est pas décentralisé : la construction reste au même endroit. Ce qui change d’échelle, c’est la couverture des besoins. L’usine absorbe une réserve de demandes qui aurait été impensable à traiter avant, et sert l’ensemble de l’organisation

• Pour qui ? Les organisations qui ont déjà un noyau technique (un DSI, un développeur référent, un architecte) et veulent garder la maîtrise de la qualité et de la sécurité
• Force : cohérence, sécurité, qualité homogène
• Limite : le débit reste borné par la taille de l’équipe centrale, qui peut redevenir un point d’engorgement

Modèle B : le développement par les métiers (décentralisé)

Les équipes métiers construisent elles-mêmes leurs outils, à l’aide d’agents, sous les garde-fous d’une plateforme centrale. C’est ici que la décentralisation prend son sens plein

L’idée clé qui rend ce modèle viable : le vrai changement de compétence n’est pas de « savoir rédiger un prompt », c’est de posséder la culture de son métier pour reconnaître un mauvais résultat en quelques minutes de lecture. Un contrôleur de gestion sait mieux que quiconque si son outil de reporting produit un chiffre faux. C’est ce jugement métier, pas la capacité à écrire du code, qui rend le modèle décentralisé sûr

• Pour qui ? Les organisations plus matures, dotées d’une plateforme et d’une gouvernance solides
• Force : débit quasi illimité, outils au plus près du besoin, autonomie des métiers
• Limite : sans garde-fous, c’est la porte ouverte au shadow IT, des dizaines de petits outils non sécurisés, non maintenus, non tracés

Où vous placer sur le continuum

Votre situation	Modèle recommandé
Pas encore de pratique, pas de plateforme	Usine centrale (A) pour apprendre et cadrer
Noyau technique en place, besoins métiers qui débordent	A qui glisse vers B sur les cas simples
Plateforme et gouvernance matures	Développement par les métiers (B) à l’échelle

La bonne stratégie n’est presque jamais « tout de suite B ». C’est commencer en A pour construire les garde-fous, puis ouvrir progressivement vers B à mesure que la plateforme et la confiance grandissent

La gouvernance qui évite le shadow IT

C’est là que se joue la réussite ou l’échec de la démarche. Décentraliser la construction de logiciels sans cadre, c’est reproduire à grande échelle le problème du shadow IA : une prolifération d’outils que personne ne contrôle

La réponse n’est pas de tout verrouiller, ce serait tuer le gain. C’est de fournir ce que le platform engineering appelle des chemins balisés : des parcours où il est plus facile de bien faire que de mal faire. Pour une plateforme qui accueille du code généré par IA dans une PME ou une ETI, je ramène l’essentiel à cinq garde-fous non négociables :

1. Périmètre d’action borné. Chaque agent et chaque outil a un domaine défini. Pas d’accès à la production, pas d’accès aux données sensibles, tant que ce n’est pas explicitement validé
2. Revue systématique avant mise en production. La boucle intention, exécution, validation humaine n’est pas optionnelle. Rien ne passe sans qu’un humain compétent ait signé
3. Traçabilité. Savoir quel code a été généré par IA, par qui, pour quel besoin. Le versionnement Git n’est pas un luxe de développeur, c’est le registre de votre patrimoine logiciel
4. Sécurité par défaut. Le code généré par IA peut introduire des vulnérabilités. Une analyse de sécurité automatisée dans la chaîne (dépendances, secrets, injections) est un prérequis, pas une option, d’autant que les agents ont un rayon d’action plus large qu’un simple outil de suggestion
5. Propriété et maintenance. Chaque outil a un propriétaire nommé. Un outil sans propriétaire est une dette qui s’ignore

Ces cinq points, ce sont exactement ceux qu’une plateforme interne de développement, même en version minimale, est faite pour porter. Vous n’avez pas besoin d’une plateforme à un million d’euros. Vous avez besoin d’un socle léger et discipliné

Comment démarrer en 90 jours

Pas de grand programme de transformation. Une boucle courte, mesurée, honnête

Semaines 1 à 2, mesurer le point de départ. Avant toute licence, avant tout agent : choisissez UN processus non critique et chronophage, et mesurez-le. Combien de temps par semaine ? Quel taux d’erreur ? Combien de personnes concernées ? Sans cette mesure de départ, vous ne saurez jamais si vous avez gagné, et vous risquez d’accélérer le mauvais maillon

Semaines 3 à 6, construire le premier outil dans un cadre de production. Pas un prototype qu’on jettera. Un outil avec les cinq garde-fous dès le départ : périmètre, revue, traçabilité, sécurité, propriétaire. Suivez la boucle explorer, planifier, construire, vérifier. C’est plus lent que le premier jet « magique », et c’est précisément ce qui fait la différence entre une usine et un tas de scripts

Semaines 7 à 10, mesurer et décider. Comparez au point de départ. Gain de temps réel ? Taux d’erreur ? Adoption par les utilisateurs ? Si le résultat est positif, vous avez une preuve chiffrée pour la direction. Sinon, vous avez appris à moindre coût

Semaines 11 à 13, industrialiser ou arrêter. Après trois mois d’exploration enthousiaste vient souvent l’essoufflement : sans cadre de production (décisions documentées, règles maison réutilisées, propriété claire), l’équipe se démotive et le comité exécutif coupe le budget. L’antidote est l’effet composé : chaque itération enrichit le contexte partagé, ce qui rend la suivante plus rapide et plus précise. On documente chaque décision une fois, pour ne jamais la reprendre

Un projet IA meurt rarement du prototype, il meurt du passage à la production. L’usine logicielle ne fait pas exception

Retour sur investissement et risques

Le « 10x » qu’on voit passer partout mérite d’être nuancé. Voici ce qui compte vraiment

Le gain est réel, mais il ne se multiplie pas sur toute la chaîne. La loi d’Amdahl est implacable : accélérer la seule écriture de code au facteur 10 ne produit jamais un facteur 10 sur la livraison totale, parce que le codage ne pèse qu’un quart à un tiers du cycle. Le reste, spécifier, revoir, sécuriser, exploiter, ne s’accélère pas mécaniquement. Le gain se concentre sur les tâches génériques bien cadrées (formulaires, extractions, rapports, opérations de base sur les données) et s’amenuise sur la logique métier complexe. Pour un outil non critique typique, c’est justement du terrain favorable

L’engorgement se déplace, il ne disparaît pas. Quand le code cesse d’être le frein, la revue devient le nouveau point de saturation, et les chaînes d’intégration montent en pression. Les études DORA notent même que, mal encadrée, l’adoption de l’IA augmente l’instabilité de livraison. C’est toute la raison d’être des garde-fous décrits plus haut

Trois risques structurels à nommer :

• La dette de complexité. Un agent peut produire beaucoup, vite, y compris du code superflu. Sans revue, la dette technique s’accumule silencieusement
• La manipulation des indicateurs. Un agent à qui on demande « fais passer les tests » peut réécrire les tests plutôt que corriger le code. La supervision humaine sur ce qu’on mesure reste essentielle
• La dépendance fournisseur. Votre usine repose sur des modèles tiers dont le prix, la disponibilité et les conditions évoluent. À intégrer dans votre analyse de risque, comme n’importe quelle dépendance critique

Ce que l’usine logicielle ne remplace pas : le jugement d’architecte sur ce qu’il faut construire, la responsabilité humaine sur l’intégrité du logiciel, et la culture métier qui permet de repérer un mauvais résultat. Le vrai frein d’une PME ou d’une ETI n’est ni le modèle ni la licence, c’est sa capacité à cadrer l’intention (l’ingénierie du contexte) et l’acceptation du risque par sa direction. Les deux se travaillent, et c’est précisément là qu’un accompagnement fait la différence

Comment Nobori accompagne les PME et ETI sur ce sujet

Nobori Partners est un cabinet de conseil SI spécialisé en Cloud, Data, IA, Architecture, DevOps et Cybersécurité. L’usine logicielle se tient exactement à l’intersection de ces métiers : c’est un sujet d’architecture (quoi construire, quoi laisser à l’ERP), de plateforme (les garde-fous), de sécurité (le code généré doit être sûr) et de conduite du changement (les équipes doivent apprendre à cadrer et à valider)

Nous ne parlons pas de ce sujet en théoriciens. Ce site même a été reconstruit avec cette approche : notre retour d’expérience technique détaille la méthode, les garde-fous et les limites d’un projet réel mené en agentic coding. Nous appliquons à nos propres outils la discipline que nous recommandons

Concrètement, notre accompagnement se décline en quatre temps :

• Cadrage : identifier les bons premiers processus (non critiques, chronophages, spécifiques), mesurer le point de départ, écarter les faux candidats et tracer la frontière avec ce qui doit rester dans l’ERP ou le CRM
• Mise en place de l’usine : la chaîne de production, les cinq garde-fous, la plateforme légère qui rend le bon usage plus simple que le mauvais
• Sécurité et gouvernance : revue du code généré, gestion des accès, traçabilité, et le cadre de conformité quand le périmètre se rapproche de données sensibles
• Montée en compétence : transmettre aux équipes techniques et métiers la culture qui permet de reconnaître un mauvais résultat, condition sans laquelle le passage au modèle décentralisé n’est pas sûr

L’objectif n’est pas de vous rendre dépendant d’un prestataire de plus. C’est l’inverse : vous doter d’une capacité interne durable, avec les garde-fous qui la rendent sûre

En résumé

L’agentic coding a fait basculer l’arbitrage entre faire et acheter en faveur du faire, pour toute une catégorie de besoins qu’on n’avait jamais les moyens de traiter. L’usine logicielle ne remplace pas l’ERP ni le CRM : elle comble les trous qu’ils laissent. Pour une PME ou une ETI, c’est une piste sérieuse, non pas pour refondre le SI, mais pour internaliser, à bas coût et au plus près des métiers, la digitalisation de ses processus non critiques

La condition n’est ni technologique ni budgétaire. Elle est disciplinaire : cadrer, gouverner, mesurer, industrialiser. Commencer petit, sur un processus sans enjeu, avec un cadre de production dès le premier jour. C’est ainsi qu’on transforme un engouement en capacité durable

Vous vous demandez par quel processus commencer, ou comment poser les garde-fous d’une première usine logicielle ? Parlons-en, un cadrage d’une heure suffit souvent à identifier le bon premier pas