Le programmeur à l’ère de l’IA : du code généré au contrôle de la non-déterminisme

baeba · 2026-06-22T10:32:20+09:00

Résumé Alors que l’IA automatise une part importante de l’écriture de code, le rôle central du développeur se déplace de l’implémentation directe vers la conception, la validation et le contrôle. L’essence du métier de programmeur ne consiste pas à taper beaucoup de code, mais à combler les détails de besoins ambigus et à les abstraire sous une forme réutilisable. Au lieu d’indiquer à l’IA comment implémenter chaque détail, il est plus efficace de lui fournir l’objectif et le contexte, puis de lui déléguer le jugement. Pour améliorer la qualité, il vaut mieux découper le travail de l’IA en livrables séparés — spécification, tests, implémentation, refactorisation, validation — plutôt que de tout demander en une fois. Comme la sortie de l’IA est non déterministe, il faut des harnais déterministes comme les tests, le compilateur, les linters et les gates de validation. Le développeur de demain se rapprochera moins d’un simple auteur de code que d’un architecte système / ingénieur de harnais, chargé de relier des agents IA à des mécanismes de validation. Introduction Une identité de développeur bousculée par l’IA Avec l’IA capable de générer des centaines de lignes de code à partir d’instructions en langage naturel, les critères traditionnels de compétence en développement évoluent. Autrefois, la capacité à écrire rapidement du code depuis un éditeur vide était considérée comme un atout majeur du développeur. Aujourd’hui, alors que l’IA fournit à la fois les connaissances et les méthodes d’implémentation, plusieurs questions émergent. Peut-on encore parler de développement sans écrire soi-même le code ? Si l’IA prend en charge les détails d’implémentation, quel rôle reste-t-il au développeur ? Les connaissances classiques en informatique et l’histoire de la programmation sont-elles encore nécessaires aujourd’hui ? L’article aborde ces questions à travers les notions de détail, abstraction, non-déterminisme et harnais. Le sens de l’histoire de la programmation Les connaissances héritées de l’histoire de la programmation ne sont pas une simple liste de techniques, mais le reflet de la manière dont les développeurs d’autrefois ont résolu des problèmes et créé de nouvelles couches d’abstraction. Le langage machine, l’assembleur, la programmation structurée, l’orienté objet et les frameworks sont nés pour masquer la complexité des couches inférieures. Même sans utiliser directement les anciennes technologies, comprendre cette histoire permet de voir comment le rôle du développeur a changé de manière répétée. Développement 1. Le développeur est celui qui concrétise les détails En général, la conception produit donne la finalité et la direction globale, mais elle ne précise pas toutes les conditions nécessaires à l’implémentation réelle. Par exemple, même une fonctionnalité aussi simple que « modifier le pseudo » implique des détails tels que : faut-il autoriser une chaîne vide ; comment gérer les caractères spéciaux et les emoji ; comment traiter les erreurs réseau et la latence de réponse ; que faire si l’utilisateur quitte l’écran pendant la modification ; où afficher les messages d’erreur et sous quelle forme. Le travail du développeur consiste à transformer ces zones floues en règles logiques et en gestion des cas limites. L’expertise du développeur réside donc moins dans l’implémentation brute d’une fonctionnalité que dans la capacité à convertir des besoins ambigus en comportement système complet. 2. L’abstraction consiste à cacher les détails déjà résolus Pour réduire le travail répétitif, les développeurs encapsulent les problèmes déjà résolus sous forme de fonctions, modules, bibliothèques ou frameworks. Le cœur de l’abstraction est le suivant : cacher les mécanismes internes répétitifs ; n’exposer que les fonctionnalités nécessaires à l’extérieur ; définir la frontière entre ce qui peut varier et ce qui doit rester fixe. Quand des abstractions robustes s’accumulent, elles forment une nouvelle couche, permettant aux développeurs du niveau supérieur de travailler sans connaître toute l’implémentation sous-jacente. L’environnement de développement actuel fonctionne sur des couches d’abstraction construites par les générations précédentes. 3. La profondeur nécessaire au développeur dépend de sa position Toutes les abstractions ne sont pas achevées. Une couche capable de masquer de manière stable son implémentation interne peut être vue comme une « abstraction terminée ». À l’inverse, une couche dont les détails internes continuent d’apparaître sous forme de problèmes de performance ou de bugs relève d’une « abstraction en cours ». Une même technologie peut donc changer de statut selon le rôle du développeur. Pour un développeur web généraliste, le navigateur est une couche relativement aboutie. Pour un développeur de moteur de navigateur, le rendu reste un problème de bas niveau à traiter directement. La profondeur nécessaire n’est pas de tout connaître, mais de comprendre suffisamment les fuites et les limites de la couche dont on a la charge. 4. L’IA est devenue une nouvelle couche d’abstraction L’IA exécute rapidement l’écriture de code et les implémentations répétitives que les développeurs faisaient auparavant eux-mêmes. Elle ne se limite donc plus à un simple outil de productivité : elle commence à agir comme une nouvelle couche qui abstrait le processus de développement lui-même. Mais le fait que l’IA génère du code ne signifie pas que l’interprétation des besoins, la conception de l’architecture, la validation de la qualité ou la responsabilité opérationnelle soient résolues automatiquement. Au contraire, à mesure que le coût de l’implémentation baisse, le coût d’assemblage et de validation du code généré devient plus important. 5. Des consignes trop détaillées peuvent limiter les performances de l’IA L’auteur a tenté de développer un side project d’interface utilisateur accessible en s’appuyant uniquement sur l’IA, sans saisir lui-même le code. Au départ, il donnait à l’IA des méthodes d’implémentation précises, mais cela a conduit l’IA à se fixer sur ces choix et à ajouter sans cesse des traitements d’exception. Le résultat a été un code plus complexe, avec divers effets de bord, et une approche standard plus appropriée n’a été adoptée que tardivement. Ce cas montre que la méthode initiale proposée par l’utilisateur peut servir d’ancre qui limite le jugement de l’IA. Au lieu de surspécifier la solution ou la structure du code, il est plus efficace de fournir : le contexte et l’objectif du problème ; le contexte du système existant ; le résultat qui doit absolument être atteint ; les contraintes qui ne doivent pas être modifiées. 6. Il faut déléguer l’objectif et le contexte plutôt que la procédure Plus les performances de l’IA augmentent, plus une délégation centrée sur l’objectif peut s’avérer efficace par rapport à une méthode où l’on prescrit chaque étape en détail. Dans cette logique, le développeur ne décide pas entièrement du « comment », mais clarifie le « pourquoi » et le « quoi ». Toutefois, une autonomie totale peut pousser l’IA à se concentrer davantage sur la modification du code elle-même que sur l’intention réelle de l’utilisateur. Il faut donc encadrer le processus de travail pour que l’IA effectue d’abord les actions suivantes : analyser l’intention de la demande ; poser des questions sur les informations manquantes ; proposer un plan de résolution ; exécuter seulement après validation de l’utilisateur. L’essentiel n’est pas de multiplier les interdictions, mais de préciser clairement quels livrables sont autorisés à l’étape en cours. 7. Une tâche ne doit viser qu’un seul livrable à la fois Un LLM est limité, dans une réponse unique, par la quantité de sortie et l’étendue du raisonnement qu’il peut produire. Si on lui demande d’écrire les tests et l’implémentation en même temps, ses ressources risquent de se concentrer sur l’objectif final — finir le code — au détriment de la qualité des tests. L’auteur découpe ainsi le travail TDD : /red : écrire uniquement des tests qui échouent ; /green : écrire l’implémentation minimale qui fait passer les tests ; /refactor : améliorer la structure du code tout en conservant les tests. Limiter chaque étape à un seul livrable réduit le risque que l’IA saute les étapes intermédiaires ou les traite de façon purement formelle. Autrement dit, le cœur du prompt design ne consiste pas à décrire longuement le comportement attendu, mais à définir le résultat à produire pour une tâche donnée. 8. Les documents Markdown et les skills deviennent le nouveau code En séparant la spécification, les tests, l’implémentation, la validation et le commit en skills distincts, on peut construire un pipeline comme suit : rédaction de la spécification ; génération des tests en échec ; implémentation de la fonctionnalité ; refactorisation ; validation ; commit. Chaque skill possède des entrées, des sorties et des contraintes, et fonctionne donc de manière analogue à une fonction. Les documents Markdown qui consignent ces skills et ces règles ne sont pas de simples guides : ils servent de règles d’exécution déterminant le comportement de l’IA. On peut y appliquer les principes classiques de conception logicielle : principe de responsabilité unique, en donnant un seul rôle à chaque skill ; modularisation, en séparant les connaissances et les règles dans des fichiers distincts ; principe ouvert/fermé, en étendant le système via des fichiers de connaissance externes sans modifier les skills centraux. Le support est passé de l’IDE aux documents Markdown, mais décomposer et relier le travail reste bien une forme de programmation. 9. Le risque central du coding avec l’IA est le non-déterminisme Un programme traditionnel renvoie généralement la même sortie pour une même entrée. L’IA, elle, peut produire des codes et des jugements différents pour une même demande. Même si une refactorisation à grande échelle menée par l’IA semble fonctionner, plusieurs problèmes demeurent : vérifier l’exactitude du code modifié ; déterminer si le code supprimé était réellement inutile ; évaluer la possibilité de nouveaux effets de bord ; assumer la maintenance et le déploiement. L’IA accélère la génération de code, mais elle n’apporte pas automatiquement la stabilité du résultat ni la responsabilité qui l’accompagne. En production, la compétence clé n’est pas tant la génération que la capacité à contrôler l’ampleur des changements et à valider le résultat. 10. L’IA est forte sur les problèmes au plafond bas Les problèmes que l’IA résout facilement sont en général des « problèmes bien définis », dont les besoins et les méthodes de résolution sont déjà largement connus. Ces problèmes peuvent être traités en combinant des éléments d’abstraction déjà établis : bibliothèques, frameworks, patterns, etc. L’IA excelle dans la combinaison probabiliste du code et des schémas de résolution accumulés par l’humanité. En revanche, des problèmes de plus haut niveau exigent encore un jugement humain supplémentaire, par exemple : des besoins incomplets ; des règles métier complexes ; les interactions dans les systèmes à grande échelle ; les cas exceptionnels en environnement de production ; les problèmes mêlant sécurité, performance, réglementation et responsabilité. La valeur de l’implémentation simple ne disparaît pas forcément, mais l’acte d’implémenter lui-même pourrait progressivement devenir accessible à des utilisateurs plus généralistes. 11. Les détails à gérer par le développeur se déplacent vers le contrôle de l’IA Autrefois, le développeur écrivait du code déterministe pour se protéger contre les entrées utilisateur imprévisibles et les environnements d’exploitation incertains. À l’ère de l’IA, il faut produire des produits déterministes à l’aide d’une IA non déterministe. Les détails que le développeur doit désormais prendre en charge se déplacent vers des domaines comme : définir le périmètre de travail pour éviter que l’IA ne se fixe sur un mauvais objectif ; définir les formats d’entrée et de sortie à chaque étape ; gérer le contexte et les documents de connaissance ; limiter l’ampleur des changements massifs ; concevoir des procédures de reprise en cas d’erreur ; valider la qualité et la sûreté des résultats. Plus les tâches d’implémentation simples sont automatisées, plus le travail du développeur risque de se concentrer sur les exceptions et le contrôle. 12. Les résultats de l’IA doivent être validés par des outils déterministes Faire vérifier les résultats générés par une IA uniquement par une autre IA ne suffit pas à obtenir une fiabilité solide. Pour juger si la sortie d’un système est correcte, il faut un critère clair de vérité — autrement dit, un oracle. Si une IA non déterministe génère aussi arbitrairement le critère de validation, elle peut corriger à tort un bon résultat ou déformer la base même de la vérification. Les critères de validation doivent donc reposer autant que possible sur des outils déterministes : compilateur et vérificateur de types ; tests automatisés ; linter et analyse statique ; validation de schéma ; critères de performance et de sécurité ; procédures d’approbation et limitation du périmètre des changements. Le jugement de l’IA peut servir d’assistance, mais la décision finale doit être reliée à des critères reproductibles. 13. Le harnais devient l’infrastructure clé du développement avec l’IA Le harnais est un dispositif de validation placé à chaque étape pour empêcher l’IA d’accumuler les erreurs ou de sortir du périmètre de travail. Ses principaux composants sont les suivants : un pipeline séparant les étapes du travail ; des formats d’entrée/sortie pour chaque étape ; des tests automatisés et de l’analyse statique ; des gates de validation qui interrompent le processus en cas d’échec ; des restrictions sur les fichiers modifiables et sur le périmètre des changements ; des procédures humaines d’approbation et de review. Le harnais empêche qu’une petite erreur à une étape ne s’amplifie dans les suivantes. La maîtrise de l’IA pourrait être évaluée moins sur la capacité à écrire de bons prompts que sur la capacité à enfermer des sorties imprévisibles dans un système stable. Conclusion Le développeur ne disparaît pas, son rôle se déplace L’IA automatise déjà rapidement l’écriture de code simple et les implémentations répétitives. Mais pour produire un résultat au niveau d’un produit, les rôles suivants restent indispensables : définir le problème et l’objectif ; concevoir l’architecture du système ; séparer les étapes de travail et les livrables ; orchestrer les flux entre agents IA ; construire les critères de validation et le harnais ; assumer la responsabilité finale des résultats en production. Le travail du développeur pourrait donc évoluer vers moins de saisie directe de code, et davantage vers l’organisation et le contrôle du code généré par l’IA à l’échelle du système. Écrire des prompts est une nouvelle forme de programmation Transformer des consignes réutilisables en skills et en règles, puis les relier dans un pipeline, ressemble fortement à la conception de fonctions et de modules. Les documents Markdown peuvent former une nouvelle couche de code qui définit le contexte, le comportement et le format de sortie de l’IA. Le développeur doit documenter son expérience et ses critères implicites de jugement afin de les abstraire dans une forme réutilisable par l’IA. Cela ne consiste plus seulement à abstraire le système existant, mais à abstraire aussi sa propre manière de travailler et de juger. Les compétences clés du développeur de demain la capacité à définir précisément les problèmes ; la capacité à déléguer le travail en se fondant sur l’objectif et le contexte ; la capacité à décomposer un travail complexe en petits livrables ; la capacité à organiser skills et agents en pipeline ; la capacité à concevoir des critères de validation déterministes ; la capacité à construire un harnais pour contrôler les risques de résultats non déterministes ; une profondeur technique suffisante pour comprendre les résultats générés par l’IA et en assumer la responsabilité finale. Évaluation d’ensemble L’IA ne supprime pas l’essence du développement, elle change la couche d’abstraction que le développeur doit manipuler. Si les développeurs d’hier géraient les détails du code et du système, ceux de demain devront gérer les détails produits par le comportement et les sorties de l’IA. Le coût de génération du code baisse, mais l’importance de la validation, de l’assemblage, de l’exploitation et du contrôle pourrait devenir encore plus grande. L’essence du métier de programmeur n’est pas la frappe au clavier, mais la capacité à repérer les détails, à les abstraire et à les organiser en systèmes fiables.

(velog.io)

6 points par baeba 5 시간 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Résumé

Alors que l’IA automatise une part importante de l’écriture de code, le rôle central du développeur se déplace de l’implémentation directe vers la conception, la validation et le contrôle.
L’essence du métier de programmeur ne consiste pas à taper beaucoup de code, mais à combler les détails de besoins ambigus et à les abstraire sous une forme réutilisable.
Au lieu d’indiquer à l’IA comment implémenter chaque détail, il est plus efficace de lui fournir l’objectif et le contexte, puis de lui déléguer le jugement.
Pour améliorer la qualité, il vaut mieux découper le travail de l’IA en livrables séparés — spécification, tests, implémentation, refactorisation, validation — plutôt que de tout demander en une fois.
Comme la sortie de l’IA est non déterministe, il faut des harnais déterministes comme les tests, le compilateur, les linters et les gates de validation.
Le développeur de demain se rapprochera moins d’un simple auteur de code que d’un architecte système / ingénieur de harnais, chargé de relier des agents IA à des mécanismes de validation.

Introduction

Une identité de développeur bousculée par l’IA

Avec l’IA capable de générer des centaines de lignes de code à partir d’instructions en langage naturel, les critères traditionnels de compétence en développement évoluent.
Autrefois, la capacité à écrire rapidement du code depuis un éditeur vide était considérée comme un atout majeur du développeur.
Aujourd’hui, alors que l’IA fournit à la fois les connaissances et les méthodes d’implémentation, plusieurs questions émergent.
- Peut-on encore parler de développement sans écrire soi-même le code ?
- Si l’IA prend en charge les détails d’implémentation, quel rôle reste-t-il au développeur ?
- Les connaissances classiques en informatique et l’histoire de la programmation sont-elles encore nécessaires aujourd’hui ?
L’article aborde ces questions à travers les notions de détail, abstraction, non-déterminisme et harnais.

Le sens de l’histoire de la programmation

Les connaissances héritées de l’histoire de la programmation ne sont pas une simple liste de techniques, mais le reflet de la manière dont les développeurs d’autrefois ont résolu des problèmes et créé de nouvelles couches d’abstraction.
Le langage machine, l’assembleur, la programmation structurée, l’orienté objet et les frameworks sont nés pour masquer la complexité des couches inférieures.
Même sans utiliser directement les anciennes technologies, comprendre cette histoire permet de voir comment le rôle du développeur a changé de manière répétée.

Développement

1. Le développeur est celui qui concrétise les détails

En général, la conception produit donne la finalité et la direction globale, mais elle ne précise pas toutes les conditions nécessaires à l’implémentation réelle.
Par exemple, même une fonctionnalité aussi simple que « modifier le pseudo » implique des détails tels que :
- faut-il autoriser une chaîne vide ;
- comment gérer les caractères spéciaux et les emoji ;
- comment traiter les erreurs réseau et la latence de réponse ;
- que faire si l’utilisateur quitte l’écran pendant la modification ;
- où afficher les messages d’erreur et sous quelle forme.
Le travail du développeur consiste à transformer ces zones floues en règles logiques et en gestion des cas limites.
L’expertise du développeur réside donc moins dans l’implémentation brute d’une fonctionnalité que dans la capacité à convertir des besoins ambigus en comportement système complet.

2. L’abstraction consiste à cacher les détails déjà résolus

Pour réduire le travail répétitif, les développeurs encapsulent les problèmes déjà résolus sous forme de fonctions, modules, bibliothèques ou frameworks.
Le cœur de l’abstraction est le suivant :
- cacher les mécanismes internes répétitifs ;
- n’exposer que les fonctionnalités nécessaires à l’extérieur ;
- définir la frontière entre ce qui peut varier et ce qui doit rester fixe.
Quand des abstractions robustes s’accumulent, elles forment une nouvelle couche, permettant aux développeurs du niveau supérieur de travailler sans connaître toute l’implémentation sous-jacente.
L’environnement de développement actuel fonctionne sur des couches d’abstraction construites par les générations précédentes.

3. La profondeur nécessaire au développeur dépend de sa position

Toutes les abstractions ne sont pas achevées.
Une couche capable de masquer de manière stable son implémentation interne peut être vue comme une « abstraction terminée ».
À l’inverse, une couche dont les détails internes continuent d’apparaître sous forme de problèmes de performance ou de bugs relève d’une « abstraction en cours ».
Une même technologie peut donc changer de statut selon le rôle du développeur.
- Pour un développeur web généraliste, le navigateur est une couche relativement aboutie.
- Pour un développeur de moteur de navigateur, le rendu reste un problème de bas niveau à traiter directement.
La profondeur nécessaire n’est pas de tout connaître, mais de comprendre suffisamment les fuites et les limites de la couche dont on a la charge.

4. L’IA est devenue une nouvelle couche d’abstraction

L’IA exécute rapidement l’écriture de code et les implémentations répétitives que les développeurs faisaient auparavant eux-mêmes.
Elle ne se limite donc plus à un simple outil de productivité : elle commence à agir comme une nouvelle couche qui abstrait le processus de développement lui-même.
Mais le fait que l’IA génère du code ne signifie pas que l’interprétation des besoins, la conception de l’architecture, la validation de la qualité ou la responsabilité opérationnelle soient résolues automatiquement.
Au contraire, à mesure que le coût de l’implémentation baisse, le coût d’assemblage et de validation du code généré devient plus important.

5. Des consignes trop détaillées peuvent limiter les performances de l’IA

L’auteur a tenté de développer un side project d’interface utilisateur accessible en s’appuyant uniquement sur l’IA, sans saisir lui-même le code.
Au départ, il donnait à l’IA des méthodes d’implémentation précises, mais cela a conduit l’IA à se fixer sur ces choix et à ajouter sans cesse des traitements d’exception.
Le résultat a été un code plus complexe, avec divers effets de bord, et une approche standard plus appropriée n’a été adoptée que tardivement.
Ce cas montre que la méthode initiale proposée par l’utilisateur peut servir d’ancre qui limite le jugement de l’IA.
Au lieu de surspécifier la solution ou la structure du code, il est plus efficace de fournir :
- le contexte et l’objectif du problème ;
- le contexte du système existant ;
- le résultat qui doit absolument être atteint ;
- les contraintes qui ne doivent pas être modifiées.

6. Il faut déléguer l’objectif et le contexte plutôt que la procédure

Plus les performances de l’IA augmentent, plus une délégation centrée sur l’objectif peut s’avérer efficace par rapport à une méthode où l’on prescrit chaque étape en détail.
Dans cette logique, le développeur ne décide pas entièrement du « comment », mais clarifie le « pourquoi » et le « quoi ».
Toutefois, une autonomie totale peut pousser l’IA à se concentrer davantage sur la modification du code elle-même que sur l’intention réelle de l’utilisateur.
Il faut donc encadrer le processus de travail pour que l’IA effectue d’abord les actions suivantes :
- analyser l’intention de la demande ;
- poser des questions sur les informations manquantes ;
- proposer un plan de résolution ;
- exécuter seulement après validation de l’utilisateur.
L’essentiel n’est pas de multiplier les interdictions, mais de préciser clairement quels livrables sont autorisés à l’étape en cours.

7. Une tâche ne doit viser qu’un seul livrable à la fois

Un LLM est limité, dans une réponse unique, par la quantité de sortie et l’étendue du raisonnement qu’il peut produire.
Si on lui demande d’écrire les tests et l’implémentation en même temps, ses ressources risquent de se concentrer sur l’objectif final — finir le code — au détriment de la qualité des tests.
L’auteur découpe ainsi le travail TDD :
- /red : écrire uniquement des tests qui échouent ;
- /green : écrire l’implémentation minimale qui fait passer les tests ;
- /refactor : améliorer la structure du code tout en conservant les tests.
Limiter chaque étape à un seul livrable réduit le risque que l’IA saute les étapes intermédiaires ou les traite de façon purement formelle.
Autrement dit, le cœur du prompt design ne consiste pas à décrire longuement le comportement attendu, mais à définir le résultat à produire pour une tâche donnée.

8. Les documents Markdown et les skills deviennent le nouveau code

En séparant la spécification, les tests, l’implémentation, la validation et le commit en skills distincts, on peut construire un pipeline comme suit :
- rédaction de la spécification ;
- génération des tests en échec ;
- implémentation de la fonctionnalité ;
- refactorisation ;
- validation ;
- commit.
Chaque skill possède des entrées, des sorties et des contraintes, et fonctionne donc de manière analogue à une fonction.
Les documents Markdown qui consignent ces skills et ces règles ne sont pas de simples guides : ils servent de règles d’exécution déterminant le comportement de l’IA.
On peut y appliquer les principes classiques de conception logicielle :
- principe de responsabilité unique, en donnant un seul rôle à chaque skill ;
- modularisation, en séparant les connaissances et les règles dans des fichiers distincts ;
- principe ouvert/fermé, en étendant le système via des fichiers de connaissance externes sans modifier les skills centraux.
Le support est passé de l’IDE aux documents Markdown, mais décomposer et relier le travail reste bien une forme de programmation.

9. Le risque central du coding avec l’IA est le non-déterminisme

Un programme traditionnel renvoie généralement la même sortie pour une même entrée.
L’IA, elle, peut produire des codes et des jugements différents pour une même demande.
Même si une refactorisation à grande échelle menée par l’IA semble fonctionner, plusieurs problèmes demeurent :
- vérifier l’exactitude du code modifié ;
- déterminer si le code supprimé était réellement inutile ;
- évaluer la possibilité de nouveaux effets de bord ;
- assumer la maintenance et le déploiement.
L’IA accélère la génération de code, mais elle n’apporte pas automatiquement la stabilité du résultat ni la responsabilité qui l’accompagne.
En production, la compétence clé n’est pas tant la génération que la capacité à contrôler l’ampleur des changements et à valider le résultat.

10. L’IA est forte sur les problèmes au plafond bas

Les problèmes que l’IA résout facilement sont en général des « problèmes bien définis », dont les besoins et les méthodes de résolution sont déjà largement connus.
Ces problèmes peuvent être traités en combinant des éléments d’abstraction déjà établis : bibliothèques, frameworks, patterns, etc.
L’IA excelle dans la combinaison probabiliste du code et des schémas de résolution accumulés par l’humanité.
En revanche, des problèmes de plus haut niveau exigent encore un jugement humain supplémentaire, par exemple :
- des besoins incomplets ;
- des règles métier complexes ;
- les interactions dans les systèmes à grande échelle ;
- les cas exceptionnels en environnement de production ;
- les problèmes mêlant sécurité, performance, réglementation et responsabilité.
La valeur de l’implémentation simple ne disparaît pas forcément, mais l’acte d’implémenter lui-même pourrait progressivement devenir accessible à des utilisateurs plus généralistes.

11. Les détails à gérer par le développeur se déplacent vers le contrôle de l’IA

Autrefois, le développeur écrivait du code déterministe pour se protéger contre les entrées utilisateur imprévisibles et les environnements d’exploitation incertains.
À l’ère de l’IA, il faut produire des produits déterministes à l’aide d’une IA non déterministe.
Les détails que le développeur doit désormais prendre en charge se déplacent vers des domaines comme :
- définir le périmètre de travail pour éviter que l’IA ne se fixe sur un mauvais objectif ;
- définir les formats d’entrée et de sortie à chaque étape ;
- gérer le contexte et les documents de connaissance ;
- limiter l’ampleur des changements massifs ;
- concevoir des procédures de reprise en cas d’erreur ;
- valider la qualité et la sûreté des résultats.
Plus les tâches d’implémentation simples sont automatisées, plus le travail du développeur risque de se concentrer sur les exceptions et le contrôle.

12. Les résultats de l’IA doivent être validés par des outils déterministes

Faire vérifier les résultats générés par une IA uniquement par une autre IA ne suffit pas à obtenir une fiabilité solide.
Pour juger si la sortie d’un système est correcte, il faut un critère clair de vérité — autrement dit, un oracle.
Si une IA non déterministe génère aussi arbitrairement le critère de validation, elle peut corriger à tort un bon résultat ou déformer la base même de la vérification.
Les critères de validation doivent donc reposer autant que possible sur des outils déterministes :
- compilateur et vérificateur de types ;
- tests automatisés ;
- linter et analyse statique ;
- validation de schéma ;
- critères de performance et de sécurité ;
- procédures d’approbation et limitation du périmètre des changements.
Le jugement de l’IA peut servir d’assistance, mais la décision finale doit être reliée à des critères reproductibles.

13. Le harnais devient l’infrastructure clé du développement avec l’IA

Le harnais est un dispositif de validation placé à chaque étape pour empêcher l’IA d’accumuler les erreurs ou de sortir du périmètre de travail.
Ses principaux composants sont les suivants :
- un pipeline séparant les étapes du travail ;
- des formats d’entrée/sortie pour chaque étape ;
- des tests automatisés et de l’analyse statique ;
- des gates de validation qui interrompent le processus en cas d’échec ;
- des restrictions sur les fichiers modifiables et sur le périmètre des changements ;
- des procédures humaines d’approbation et de review.
Le harnais empêche qu’une petite erreur à une étape ne s’amplifie dans les suivantes.
La maîtrise de l’IA pourrait être évaluée moins sur la capacité à écrire de bons prompts que sur la capacité à enfermer des sorties imprévisibles dans un système stable.

Conclusion

Le développeur ne disparaît pas, son rôle se déplace

L’IA automatise déjà rapidement l’écriture de code simple et les implémentations répétitives.
Mais pour produire un résultat au niveau d’un produit, les rôles suivants restent indispensables :
- définir le problème et l’objectif ;
- concevoir l’architecture du système ;
- séparer les étapes de travail et les livrables ;
- orchestrer les flux entre agents IA ;
- construire les critères de validation et le harnais ;
- assumer la responsabilité finale des résultats en production.
Le travail du développeur pourrait donc évoluer vers moins de saisie directe de code, et davantage vers l’organisation et le contrôle du code généré par l’IA à l’échelle du système.

Écrire des prompts est une nouvelle forme de programmation

Transformer des consignes réutilisables en skills et en règles, puis les relier dans un pipeline, ressemble fortement à la conception de fonctions et de modules.
Les documents Markdown peuvent former une nouvelle couche de code qui définit le contexte, le comportement et le format de sortie de l’IA.
Le développeur doit documenter son expérience et ses critères implicites de jugement afin de les abstraire dans une forme réutilisable par l’IA.
Cela ne consiste plus seulement à abstraire le système existant, mais à abstraire aussi sa propre manière de travailler et de juger.

Les compétences clés du développeur de demain

la capacité à définir précisément les problèmes ;
la capacité à déléguer le travail en se fondant sur l’objectif et le contexte ;
la capacité à décomposer un travail complexe en petits livrables ;
la capacité à organiser skills et agents en pipeline ;
la capacité à concevoir des critères de validation déterministes ;
la capacité à construire un harnais pour contrôler les risques de résultats non déterministes ;
une profondeur technique suffisante pour comprendre les résultats générés par l’IA et en assumer la responsabilité finale.

Évaluation d’ensemble

L’IA ne supprime pas l’essence du développement, elle change la couche d’abstraction que le développeur doit manipuler.
Si les développeurs d’hier géraient les détails du code et du système, ceux de demain devront gérer les détails produits par le comportement et les sorties de l’IA.
Le coût de génération du code baisse, mais l’importance de la validation, de l’assemblage, de l’exploitation et du contrôle pourrait devenir encore plus grande.
L’essence du métier de programmeur n’est pas la frappe au clavier, mais la capacité à repérer les détails, à les abstraire et à les organiser en systèmes fiables.