L’IA rend absurde de garder les ingénieurs loin du réel

Pendant longtemps, le logiciel a été limité par une contrainte très simple : produire du code coûtait cher.

Il fallait beaucoup de temps pour transformer une idée en interface, une interface en logique métier, une logique métier en système fiable, puis ce système en produit utilisable en production.

Cette contrainte a structuré les entreprises.

On a séparé les rôles.

On a spécialisé les fonctions.

On a multiplié les filtres entre le client et la personne qui construit réellement le produit.

Le client parle à quelqu’un.

Cette personne reformule.

Un product manager priorise.

Un designer matérialise.

Un ingénieur implémente.

Puis le logiciel arrive en production.

Ce modèle avait une logique. Quand le coût de production est élevé, il faut protéger la capacité de production. Il faut éviter que les ingénieurs soient interrompus, dispersés, sollicités de partout. Leur temps est rare, donc on les place souvent en bout de chaîne.

Mais l’IA change cette contrainte.

Elle ne supprime pas le travail d’ingénierie. Elle ne remplace pas le jugement. Elle ne rend pas la conception facile. Mais elle réduit fortement le coût marginal de production du code. Elle permet de générer, modifier, tester, explorer et comparer des solutions beaucoup plus vite.

Et quand le coût de production baisse, la question centrale change.

La question n’est plus seulement :

Comment produire plus de logiciel ?

Elle devient :

Comment produire du logiciel plus juste ?

Le signal GitLab#

L’annonce récente de GitLab est intéressante parce qu’elle rend visible ce déplacement.

Dans son annonce “GitLab Act 2”, GitLab explique vouloir restructurer l’entreprise pour s’adapter à l’ère agentique : organisation plus plate, jusqu’à trois couches de management supprimées dans certaines fonctions, R&D réorganisée en environ soixante petites équipes plus autonomes avec une responsabilité end-to-end, et nouveaux principes opérationnels centrés sur la vitesse avec qualité, l’ownership et les résultats clients. GitLab affirme aussi que le logiciel sera de plus en plus construit par des machines dirigées par des humains, mais que les humains gardent les jugements essentiels : l’architecture, la compréhension profonde du problème client, et les arbitrages qui demandent du goût.

C’est exactement le point important.

Le message n’est pas seulement : “nous allons automatiser davantage”.

Le message plus profond est :

Si les machines peuvent produire davantage, alors les humains doivent se rapprocher des endroits où leur jugement compte vraiment.

Et l’un de ces endroits, c’est la compréhension du problème réel.

Le sous-usage des ingénieurs logiciels#

Dans beaucoup d’organisations, les ingénieurs logiciels sont encore utilisés comme une force d’implémentation.

Ils reçoivent des tickets.

Ils reçoivent des spécifications.

Ils reçoivent des maquettes.

Ils reçoivent des décisions déjà prises.

Puis ils traduisent tout cela en code.

Mais c’est un sous-usage massif de leur valeur.

Un bon ingénieur logiciel ne fait pas seulement “du code”. Il comprend des systèmes. Il voit les dépendances cachées, les états implicites, les invariants fragiles, les frontières mal placées, les abstractions qui vont casser, les responsabilités mal distribuées.

Il sait qu’une solution produit n’est pas seulement une fonctionnalité visible. C’est une transformation d’un problème réel en système exécutable.

Et pour faire correctement cette transformation, il faut comprendre le problème.

Pas seulement le ticket.

Pas seulement la user story.

Pas seulement la roadmap.

Le problème.

Le médecin sans patient#

Il y a une comparaison simple.

Demander à un ingénieur de construire un logiciel qui résout un problème client sans le mettre en contact avec ce problème, c’est comme demander à un médecin de soigner un patient sans jamais le voir.

On trouverait cela absurde.

Un médecin a besoin d’écouter le patient.

Il a besoin d’observer les symptômes.

Il a besoin de distinguer ce qui est dit, ce qui est vécu, ce qui est mesurable, ce qui est interprété.

Il a besoin de poser des questions.

Il a besoin de vérifier si le traitement produit réellement un effet.

Or, dans le logiciel, on accepte souvent l’inverse.

On éloigne les ingénieurs du réel.

On leur donne des résumés.

On leur donne des solutions déjà formulées.

On leur demande de soigner un problème qu’ils n’ont jamais observé.

Cela pouvait se justifier lorsque le temps d’ingénierie était presque entièrement absorbé par la production. Mais si l’IA libère une partie de ce temps, alors il faut le réallouer là où il crée le plus de valeur.

Et l’endroit évident, c’est le contact avec le réel.

L’ingénieur comme traducteur entre le réel et la machine#

Il y a un paradoxe amusant dans le discours actuel sur l’IA.

Pendant un moment, on a beaucoup entendu que les ingénieurs logiciels allaient être remplacés. Puisque l’IA peut écrire du code, alors le métier d’ingénieur deviendrait moins important.

Je pense que c’est probablement l’inverse qui va se produire.

L’IA ne supprime pas le besoin d’ingénieurs. Elle augmente l’importance des ingénieurs capables de comprendre à la fois ce que disent les humains et ce que produit la machine.

D’un côté, il y a les humains : leurs problèmes, leurs contraintes, leurs habitudes, leurs frustrations, leurs contradictions, leurs demandes parfois mal formulées.

De l’autre, il y a la machine : du code généré, des architectures proposées, des agents capables d’exécuter, des systèmes qui peuvent produire très vite mais qui ne savent pas toujours pourquoi ils produisent.

Entre les deux, il faut quelqu’un qui comprend les deux langues.

C’est là que les meilleurs ingénieurs deviennent centraux.

Ils comprennent assez le réel pour ne pas construire une solution hors-sol.

Ils comprennent assez le système pour ne pas accepter naïvement ce que la machine génère.

Ils savent transformer un problème humain en système technique.

Ils savent relire, guider, corriger et contraindre la production de l’IA.

Ils savent distinguer un code qui fonctionne d’un système qui tient.

Dans ce monde, la valeur ne se trouve pas seulement dans la capacité à écrire du code. Elle se trouve dans la capacité à faire le lien entre :

problème humain
  -> modèle mental
  -> architecture
  -> code généré ou écrit
  -> production
  -> retour du réel

C’est probablement pour cela que les très bons ingénieurs ne vont pas devenir moins importants.

Ils vont devenir plus importants.

Pas tous les ingénieurs. Pas ceux qui se limitent à exécuter des tickets ou à produire mécaniquement du code. Mais ceux qui savent comprendre, modéliser, arbitrer, guider la machine et ramener le système vers le réel.

L’IA ne remplace pas cette compétence.

Elle la rend plus visible.

Pourquoi les outils développeurs ont autant innové#

Il y a un domaine où cette boucle courte a toujours existé : les outils pour développeurs.

Ce n’est probablement pas un hasard si l’innovation y a été aussi forte.

Les développeurs avaient eux-mêmes les problèmes. Ils ressentaient directement la friction : un build trop lent, un déploiement trop fragile, une API pénible, un framework trop lourd, une erreur difficile à diagnostiquer, une architecture qui dérive, une boucle de feedback trop lente.

Et surtout, ils avaient la capacité de construire les solutions.

Le problème et le pouvoir de résolution étaient au même endroit.

C’est une situation extrêmement favorable à l’innovation. Il y a peu de traduction, peu de distance, peu de perte d’information. Celui qui souffre du problème peut formuler une hypothèse, construire un outil, l’utiliser immédiatement, observer ce qui marche, puis l’améliorer.

friction vécue
  -> outil construit
  -> usage direct
  -> feedback immédiat
  -> itération rapide

C’est une boucle beaucoup plus courte que dans la plupart des autres industries logicielles.

Dans beaucoup de produits B2B ou métiers, l’ingénieur est loin du problème. Il reçoit une version traduite du réel : un ticket, une spec, une demande priorisée, une maquette. Le problème a déjà été interprété plusieurs fois avant d’arriver jusqu’à lui.

Avec l’IA, cette distance devient moins justifiable.

Si les ingénieurs peuvent produire plus vite, alors ils peuvent passer plus de temps là où l’innovation naît vraiment : au contact direct des problèmes. Ils peuvent observer les utilisateurs, comprendre les situations, repérer les frictions, puis transformer rapidement cette compréhension en système.

Autrement dit, une partie des logiciels métiers pourrait être réécrite avec une boucle beaucoup plus proche de celle des outils développeurs.

Pas parce que tous les domaines deviendront simples.

Pas parce que les intermédiaires disparaîtront.

Mais parce que la distance entre ceux qui vivent le problème et ceux qui construisent la solution peut se réduire.

Et cette réduction de distance est probablement l’un des grands effets organisationnels de l’IA.

Le futur du logiciel ne sera pas seulement plus productif. Il pourrait être plus proche du réel.

Le vrai full stack#

On a longtemps utilisé l’expression “full stack” pour parler de quelqu’un capable de travailler à la fois sur le frontend, le backend, la base de données, parfois l’infrastructure.

Mais cette définition devient trop étroite.

Dans l’ère de l’IA, le vrai full stack n’est pas seulement technique.

Le vrai full stack va du client à la production.

client
  -> problème
  -> compréhension
  -> conception
  -> système
  -> code
  -> production
  -> observation
  -> itération

C’est cela, la boucle complète.

Un ingénieur vraiment utile ne possède pas seulement plusieurs couches techniques. Il possède une partie de cette boucle. Il comprend pourquoi le système existe, ce qu’il doit transformer, comment il échoue, comment il se comporte en production, et comment les utilisateurs réagissent réellement.

Ce n’est pas seulement un product engineer au sens classique.

C’est un ingénieur du problème au système.

Ou, pour garder une expression plus naturelle :

un full-cycle product engineer.

Mais avec une définition forte :

Un full-cycle product engineer ne possède pas seulement une partie de la stack technique. Il possède une boucle complète : client, problème, solution, système, production, observation, itération.

Le rôle du product manager ne disparaît pas#

Cela ne veut pas dire que les product managers, designers, customer success ou sales deviennent inutiles.

Ce serait une mauvaise conclusion.

Le sujet n’est pas de remplacer une chaîne de spécialistes par des ingénieurs qui feraient tout. Le sujet est de réduire les filtres inutiles entre les personnes qui comprennent le réel et les personnes qui construisent le système.

Dans certains contextes, le product manager reste essentiel. Il structure la stratégie, arbitre les priorités, synthétise plusieurs signaux, comprend le marché, travaille sur le positionnement, la distribution, les contraintes business.

Le designer reste essentiel. Il travaille la perception, l’usage, l’attention, la lisibilité, l’expérience concrète.

Le customer success reste essentiel. Il observe les usages réels, les blocages, les frustrations, les conditions d’adoption.

Mais l’ingénieur ne devrait pas être seulement le dernier maillon technique de cette chaîne.

Il doit participer plus tôt.

Il doit entendre certains problèmes directement.

Il doit observer les conséquences de ce qu’il construit.

Il doit pouvoir relier une décision technique à un effet client.

Sinon, on perd une partie énorme de son intelligence.

Ce que l’IA rend possible#

L’IA permet de réduire une partie du temps passé sur la production mécanique.

Écrire du boilerplate.

Créer une première version.

Générer des variations.

Refactorer une structure.

Produire des tests.

Explorer plusieurs options.

Documenter.

Auditer.

Comparer.

Tout cela ne devient pas gratuit. Mais cela devient plus rapide.

La mauvaise réaction serait d’utiliser tout ce gain pour produire encore plus de fonctionnalités, encore plus vite, avec encore moins de compréhension.

Ce serait simplement accélérer la mauvaise boucle.

La bonne réaction est différente :

utiliser le temps libéré pour mieux comprendre, mieux concevoir, mieux vérifier.

Cela veut dire plus de temps avec les utilisateurs.

Plus de temps à observer les workflows réels.

Plus de temps à comprendre les exceptions.

Plus de temps à clarifier les invariants métier.

Plus de temps à instrumenter la production.

Plus de temps à fermer la boucle entre problème, solution et résultat.

L’IA ne doit pas seulement augmenter le débit de code.

Elle doit augmenter la qualité de la boucle d’apprentissage.

Le logiciel est un système, pas une réponse à un ticket#

Un logiciel robuste n’est pas une accumulation de fonctionnalités. C’est un système.

Il a des frontières.

Il a des contrats.

Il valide ce qui vient de l’extérieur.

Il protège des invariants.

Il rend ses états explicites.

Il clarifie les responsabilités.

Il transforme les données de manière déterministe.

Il fournit des preuves.

Il devient observable.

Mais ces éléments ne peuvent pas être bien conçus si le problème réel est mal compris.

Une frontière technique correspond souvent à une frontière métier.

Un contrat logiciel correspond souvent à une promesse entre deux parties du système.

Un invariant correspond souvent à une règle du réel qui ne doit jamais être violée.

Un état explicite correspond souvent à un moment important du cycle de vie utilisateur.

Une observabilité utile correspond souvent à une question métier qu’on voudra poser plus tard.

Si l’ingénieur ne voit jamais le réel, il ne peut pas bien modéliser ces choses.

Il peut produire du code propre.

Il peut respecter des patterns.

Il peut suivre une architecture.

Mais il risque de construire un système techniquement cohérent autour d’une mauvaise compréhension du problème.

Les petites équipes ont un avantage#

Cette thèse est particulièrement importante pour les petites structures.

Dans une grande entreprise, il y a souvent des raisons organisationnelles de spécialiser fortement les rôles. Il y a de la complexité politique, commerciale, contractuelle, réglementaire. Tout ne peut pas être plat. Tout ne peut pas être direct.

Mais dans une startup, une petite équipe produit ou un studio logiciel, éloigner les ingénieurs du client est souvent une perte sèche.

Une petite équipe peut fonctionner autrement.

Elle peut avoir des ingénieurs qui parlent aux utilisateurs.

Elle peut faire des prototypes rapides.

Elle peut mettre en production tôt.

Elle peut observer directement les usages.

Elle peut corriger sans attendre trois cycles de validation.

Elle peut garder une boucle courte entre le problème et le système.

C’est probablement l’un des grands avantages des petites structures dans l’ère de l’IA.

Elles n’ont pas seulement moins de dette organisationnelle.

Elles peuvent aussi construire des boucles plus directes.

Et dans un monde où produire du code devient plus facile, la qualité de la boucle devient un avantage stratégique.

Le risque : produire plus de bruit#

Il y a toutefois un risque évident.

Si l’IA permet de produire plus vite, beaucoup d’entreprises vont simplement produire plus.

Plus de features.

Plus d’écrans.

Plus d’automatisations.

Plus de dashboards.

Plus de workflows.

Plus de complexité.

Mais produire plus n’est pas forcément créer plus de valeur.

On peut très bien utiliser l’IA pour accélérer la production de logiciels inutiles, mal ciblés, mal intégrés, mal observés, ou qui déplacent simplement la complexité vers l’utilisateur.

C’est même probablement l’un des grands dangers de la période actuelle.

Quand le coût de production baisse, la discipline doit augmenter.

Sinon, on crée une inflation logicielle : plus de code, plus de surface, plus de maintenance, plus de confusion, mais pas nécessairement plus de résolution réelle.

La question centrale doit donc rester :

Quel problème réel ce système résout-il, pour qui, dans quelle situation, avec quel effet observable ?

Une nouvelle allocation du temps ingénieur#

Le temps gagné par l’IA ne devrait pas être automatiquement réinjecté dans plus de production.

Il devrait être réalloué.

Moins de temps sur la mécanique.

Plus de temps sur le réel.

Moins de temps à exécuter des tickets.

Plus de temps à comprendre les situations.

Moins de temps à produire des écrans.

Plus de temps à vérifier que ces écrans changent quelque chose.

Moins de temps à maintenir des abstractions accidentelles.

Plus de temps à concevoir des systèmes qui correspondent au problème.

Ce changement n’est pas seulement technique. Il est organisationnel.

Il demande de faire confiance aux ingénieurs.

Il demande de les exposer davantage aux utilisateurs.

Il demande de réduire les handoffs.

Il demande de mesurer les résultats clients plutôt que l’activité interne.

Il demande de considérer l’ingénierie comme une fonction de compréhension, pas seulement comme une fonction de production.

La thèse#

La thèse est simple :

Quand l’IA réduit le coût de production du code, garder les ingénieurs loin du réel devient absurde.

Pas parce que les ingénieurs devraient tout faire.

Mais parce qu’ils sont parmi les mieux placés pour transformer un problème réel en système robuste.

Si on les garde loin du client, on les prive de la matière première de leur jugement.

Si on les réduit à l’implémentation, on gaspille leur capacité à modéliser.

Si on leur donne seulement des tickets, on les empêche de construire les bons systèmes.

L’IA ne rend pas les ingénieurs moins importants.

Elle rend plus visible ce qui a toujours été leur vraie valeur : comprendre un problème, concevoir un système, le faire exister en production, observer ce qu’il produit, puis l’améliorer.

Le futur intéressant du logiciel n’est donc pas seulement celui où les ingénieurs écrivent plus vite.

C’est celui où ils sont enfin replacés au bon endroit :

près du problème,

près du client,

près du système,

près du réel.