Je constate une pression croissante pour que les développeurs fassent appel systématiquement à l’IA générative dans tous les domaines. Et je vois que remettre cela en question frôle l’hérésie dans le secteur.
Aujourd’hui, il existe une narration implicite selon laquelle les équipes qui n’adopteront pas les copilotes, les agents et les workflows « AI-first » finiront inévitablement par prendre du retard. Mais franchement, je ne pense pas que le débat soit mené avec suffisamment d’honnêteté. Non pas parce que ces outils sont inutiles. Ils présentent clairement une utilité. Le problème, à mon sens, est autre : nous confondons accélération ponctuelle et maturité structurelle. Je vois ainsi beaucoup de personnes célébrer la vitesse sans discuter de dépendance, d’érosion des savoirs, de perte de contexte et de dégradation progressive de la capacité d’ingénierie.
Les modèles génèrent du code plausible avec une facilité impressionnante. Cela crée une impression continue de productivité. Or la plausibilité n’est pas de la compréhension. Et une productivité apparente ne signifie pas nécessairement une qualité durable.
Il existe un effet psychologique dangereux dans tout cela. Plus le système paraît fluide, plus nous commençons à lui faire confiance au-delà du raisonnable. Peu à peu, une révision minutieuse devient une validation superficielle. Une compréhension profonde se transforme en curation des résultats. L’ingénierie se met à se muer en supervision probabiliste. Et cela modifie même la relation du développeur avec son travail.
La programmation exige une concentration prolongée, une construction mentale de l’architecture, une compréhension accumulée et un raisonnement causal sur les conséquences. Or, de nombreux workflows fondés sur un chat constant finissent par favoriser des interruptions continues, une fragmentation cognitive et une externalisation partielle de la pensée.
Cette question me préoccupe également quant à la formation professionnelle. Les développeurs expérimentés ont été formés en résolvant des problèmes difficiles, en gérant des ambiguïtés, en déboguant des systèmes complexes et en accumulant du contexte au fil des années. Mais que se passe-t-il lorsque les étapes intermédiaires d’apprentissage commencent à être absorbées par l’IA ? Peut-être que nous créons une génération extrêmement efficace à utiliser des outils, mais progressivement moins préparée à comprendre les systèmes en profondeur.
Il existe aussi une question économique peu discutée. Le modèle actuel dépend de subventions massives des géants de la tech. Les tarifs paraissent bas car le marché n’est pas encore pleinement capté. Mais quel est le coût de cette dépendance lorsque des flux de travail entiers dépendent de plateformes externes, d’API propriétaires et de modèles dont le coût opérationnel demeure colossal ?
En fin de compte, ma préoccupation ne porte pas sur l’existence de ces outils. Elle consiste dans la vitesse à laquelle nous réorganisons le développement logiciel autour d’eux sans comprendre pleinement les effets cognitifs, organisationnels et économiques de ce changement.
À mes yeux, la question n’est pas « combien de code l’IA peut générer », mais combien de compréhension humaine sommes-nous prêts à substituer dans le processus.
