Le logiciel ne s’écrit plus seulement à la main. Il se produit. Et tout ce qui se produit relève, tôt ou tard, du génie industriel.
Introduction
Plusieurs disciplines de l’ingénierie sont aujourd’hui remises en question par l’arrivée de l’intelligence artificielle. Le génie informatique et le génie logiciel en premier lieu : quand un modèle écrit du code compétent en quelques secondes, la question de ce que devient l’ingénieur qui l’écrivait devient difficile à éviter. La discussion est partout, et elle est légitime.
Mais elle ne s’arrête pas là. Une autre discipline est touchée, plus discrètement, et c’est la mienne : le génie industriel.
À première vue, le lien n’est pas évident. Le génie industriel s’occupe d’usines, de lignes d’assemblage, de flux de matière, de goulots d’étranglement, de temps de cycle. L’IA, elle, produit du texte et du raisonnement. Deux mondes qui ne se croisent pas.
Sauf qu’ils se croisent précisément là où l’on cesse de voir l’IA comme un outil et où l’on commence à la voir comme un moyen de production. Dès qu’un système produit des unités — des pièces, des dossiers, des décisions, des fonctionnalités logicielles — il possède une capacité théorique, des pertes, un débit, un taux de rejet. Il devient un système à concevoir et à optimiser. Et concevoir des systèmes de production, c’est très exactement le métier.
L’IA déplace l’objet du génie industriel
Pendant un siècle, le génie industriel a eu un objet stable : des processus opérés par des humains, assistés par des machines. On observait le travail, on le décomposait, on éliminait le gaspillage, on équilibrait la ligne, on standardisait, on mesurait, on recommençait. Taylor, Toyota, Lean, Six Sigma — les écoles diffèrent, la logique reste la même.
Ce qui change avec l’IA n’est pas cette logique. C’est ce sur quoi elle s’applique.
Nous pouvons aujourd’hui construire des usines complètes autour de processus jusqu’ici opérés par des humains. Un flux de traitement de commandes, un processus d’estimation, une chaîne de conformité, un cycle de support client : ce sont des lignes de production. Elles ont des postes, des transferts entre postes, des files d’attente, des reprises. Elles n’ont simplement jamais eu de convoyeurs visibles.
Ces processus étaient hors de portée de l’automatisation classique parce qu’ils exigeaient du jugement. Lire un devis mal formaté, décider si une exception est acceptable, arbitrer entre deux interprétations d’une clause. On pouvait automatiser autour de ces décisions, jamais les décisions elles-mêmes. Les agents changent cela : le jugement devient une opération que l’on peut poster sur une ligne.
Et quand le jugement devient une opération, tout l’outillage du génie industriel redevient applicable — mais sur un terrain neuf. L’ingénieur industriel n’a pas à réapprendre son métier. Il a à l’appliquer à une matière qu’il n’avait jamais eu le droit de toucher.
L’usine à code
L’exemple le plus abouti de ce déplacement est aussi le plus ironique : c’est la fabrication du logiciel elle-même.
L’idée tient en une phrase. On cesse d’écrire le logiciel directement, et on construit le système qui écrit le logiciel. On reste ingénieur ; on opère simplement à un autre niveau. On passe de « j’écris le code » à « je construis la ligne qui produit le code ». Cette ligne, appelons-la l’usine à code — le software factory.
Une usine à code est le système par lequel un logiciel est produit et livré à ses utilisateurs. Elle est sociotechnique : des humains qui décident, et des machines qui exécutent. Et elle est un système au sens strict — des parties interdépendantes qui forment un tout, de l’idée jusqu’à la mise en production.
Ce qui frappe, c’est que toute organisation qui produit du logiciel possède déjà une usine à code. Le backlog, la répartition des tâches, le sprint, la revue de code, l’intégration continue, le déploiement : c’est une ligne de production. Elle a un temps de cycle, un en-cours, des reprises, un taux de rejet. Personne ne l’a jamais appelée ainsi, et surtout, personne ne l’a jamais conçue comme telle. Elle a émergé.
C’est exactement la situation d’un atelier qui a grandi par accumulation : chaque poste a été ajouté quand le besoin s’est présenté, l’implantation n’a jamais été pensée, et le flux serpente entre les machines. Ça fonctionne. Ce n’est pas conçu.
Voir la ligne d’assemblage
Le déclic arrive quand on regarde cette chaîne avec l’œil d’un ingénieur industriel. Une usine à code bien construite a exactement la structure d’une ligne d’assemblage, poste par poste.
L’entrée de ligne. Une demande arrive — un bogue, une fonctionnalité. Un humain décide si elle entre en production. C’est l’ordonnancement, et c’est un poste de décision, pas d’exécution.
Le poste de planification. Un agent analyse la demande, la reproduit, propose un plan. Le plan est le gamme de fabrication : il dit dans quel ordre les opérations se font.
Les postes de contrôle amont. Avant qu’une seule ligne de code soit écrite, le plan est confronté à un ensemble de politiques — l’architecture retenue, la stratégie de test, la posture de sécurité, l’accessibilité, l’observabilité. Chacune est un contrôle qualité en amont, appliqué par un agent dédié dont c’est la seule préoccupation. Le génie industriel connaît bien ce principe : un défaut détecté au poste où il est créé coûte une fraction de ce qu’il coûte détecté en fin de ligne.
Les postes d’usinage. Le code est écrit, les tests sont écrits, les tests sont exécutés. Si un test échoue, la pièce repasse au poste — une boucle de reprise locale, bornée, comme une reprise en cellule plutôt qu’un retour en début de ligne.
Les postes de contrôle aval. Le code produit repasse devant les mêmes politiques, cette fois pour vérifier le résultat et non l’intention. Un contrôle par dimension, un agent par dimension. Une seule inspection couvrant dix critères se disperse ; dix inspections d’un critère chacune trouvent ce qu’elles cherchent.
L’assemblage final et l’expédition. Le code est intégré, un artefact de production est construit et stocké.
La réception. L’artefact est testé en boîte noire, de l’extérieur, comme un client l’utiliserait — sans accès au code. C’est la vieille recette de l’assurance qualité, celle des équipes qui déroulaient un cahier de tests à la main avant de graver un CD. On l’avait abandonnée parce qu’elle était trop lente. Elle redevient viable parce qu’une machine peut la dérouler en continu.
Ce dernier poste mérite d’être souligné, parce que c’est lui qui rend le reste sûr. Tant que la validation appartient au même système qui produit, elle valide sa propre interprétation du besoin. Une réception indépendante, qui ne connaît que les exigences de l’utilisateur et l’artefact fini, est ce qui permet de refondre massivement une ligne sans crainte. En manufacturier, c’est le contrôle de conformité final. En logiciel, c’est ce qui autorise le refactoring à grande échelle.
L’humain, lui, n’intervient qu’à deux endroits : il approuve le plan, et il approuve le résultat. Entre les deux, la ligne tourne.
Ce que l’ingénieur industriel apporte ici
C’est là que la profession trouve sa place, et elle est plus large qu’elle n’y paraît.
L’architecture de ligne. Quels postes, dans quel ordre, avec quels tampons entre eux. Quelles boucles de reprise sont locales et lesquelles renvoient en amont. Où placer les contrôles. Un ingénieur logiciel pense en composants ; un ingénieur industriel pense en flux. Les deux sont nécessaires, et le second manque presque partout.
La standardisation. Une ligne ne devient performante que si le travail y est standardisé. En usine à code, cela prend la forme de politiques écrites et d’exemples de référence — voici comment on structure ce type de composant, voici à quoi ressemble un bon test, voici notre norme d’accessibilité. Ce sont des instructions de poste. Les machines, elles, les suivent sans négocier. C’est une différence notable avec les opérateurs humains, qui avaient historiquement d’excellentes raisons de résister à la standardisation excessive.
La détection des goulots. Une usine à code a des goulots et ils sont mesurables : le temps d’attente d’une approbation humaine, le nombre de tours de boucle avant qu’un code passe la revue, la proportion de travail qui revient en amont après la réception. Ce sont des mesures de ligne classiques appliquées à une matière nouvelle.
Le dimensionnement des lots et des voies. Toute demande ne mérite pas de traverser la ligne complète. Une correction triviale qui subit sept contrôles est du gaspillage. Une voie rapide pour les tâches simples, une voie complète pour le reste : c’est de l’équilibrage de ligne, et c’est un réflexe de la discipline.
La mesure du rendement. C’est le prolongement naturel de ce que j’ai proposé ailleurs avec le Taux de Rendement Cognitif : une unité de production cognitive a une capacité théorique, des pertes, un taux de rejet. Une usine à code est l’endroit où ce cadre devient directement opérationnel, parce que chaque poste y est instrumentable.
Ce qui casse quand le débit change d’ordre de grandeur
Il faut être honnête sur l’ampleur de ce que cela déclenche.
Peu de systèmes survivent à une multiplication par dix de leur débit. C’est vrai d’une canalisation, c’est vrai d’une ligne de production, et c’est vrai d’une organisation. Quand le délai entre une idée et sa mise en production passe de plusieurs semaines à quelques heures, ce n’est pas seulement la vitesse qui change. Ce sont les files d’attente en amont, le dimensionnement des équipes, les rituels de coordination, les contrats de service, la structure des approbations. Tout ce qui avait été calibré pour un rythme mensuel devient inadapté.
C’est un problème de génie industriel avant d’être un problème de technologie. Augmenter la cadence d’un poste sans rééquilibrer la ligne ne produit pas plus — cela déplace simplement le goulot, accumule de l’en-cours devant le poste suivant, et dégrade souvent le tout. Toute personne ayant fait de l’optimisation de flux a vu ce scénario. Il est en train de se rejouer, à l’échelle de la production logicielle.
Et il y a une seconde vague : l’usine construite avec ce premier gain de débit servira à construire la suivante. Personne ne sait où cela s’arrête, et c’est précisément pour cela que l’approche doit être celle d’une conception de système — itérative, mesurée, corrigée — plutôt que celle d’une adoption d’outil.
En conclusion
L’intelligence artificielle remet effectivement en question plusieurs disciplines de l’ingénierie. Pour le génie industriel, je ne crois pas que la question soit celle du remplacement. Elle est celle de l’élargissement du terrain.
Pendant un siècle, la discipline s’est appliquée à ce qui se fabrique. Elle peut désormais s’appliquer à ce qui se décide, se rédige, se code — à condition d’accepter de voir ces activités pour ce qu’elles sont : des processus de production, avec leur capacité, leurs pertes et leur rendement.
L’usine à code n’est qu’un exemple, mais c’est l’exemple le plus avancé, et il est révélateur. Le jour où l’industrie logicielle s’est mise à décrire sa propre chaîne de production en termes de postes, de flux, de contrôles qualité et de taux de rejet, elle a, sans toujours le savoir, ouvert la porte à une discipline qui travaille ces questions depuis cent ans.
Le rôle de l’ingénieur industriel dans le monde numérique n’est pas d’écrire le code. Il est de concevoir, mesurer et optimiser la machine qui l’écrit.