L'éducation et l'évaluation des développeurs à l'ère des agents

L'éducation et l'évaluation des développeurs à l'ère des agents

Cette analyse reflète le paysage de l'éducation et de la certification au 26 juillet 2026.

Introduction

Les agents de codage autonomes transforment le développement logiciel, passant d'une tâche centrée sur la saisie de code à une tâche centrée sur la spécification du travail, la délégation des tâches, la supervision de l'exécution et l'examen des résultats.

Les agents de codage modernes peuvent inspecter un dépôt, élaborer un plan d'implémentation, modifier plusieurs fichiers, exécuter des tests, réagir aux erreurs et ouvrir une pull request pour examen humain. La documentation actuelle de GitHub décrit des flux de travail dans lesquels les développeurs assignent des problèmes aux agents, surveillent leur travail, demandent des revues de code, fournissent des commentaires et approuvent ou rejettent le résultat. (docs.github.com)

Cela soulève une question difficile pour l'éducation :

Si un étudiant peut demander à un agent de produire un programme fonctionnel, qu'est-ce que l'étudiant devrait être tenu de comprendre ?

La réponse n'est pas d'abandonner les fondamentaux de la programmation. Il s'agit de modifier l'usage de ces fondamentaux.

Les étudiants doivent toujours comprendre les structures de données, les algorithmes, les langages de programmation, la conception de systèmes, la sécurité, les tests et le débogage. Cependant, ils doivent de plus en plus appliquer ces connaissances pour :

• Décomposer des problèmes ambigus en tâches gérables
• Rédiger des spécifications et des critères d'acceptation précis
• Fournir un contexte utile aux agents de codage
• Juger si le code généré est correct et maintenable
• Concevoir des tests qui révèlent les défaillances cachées
• Examiner les risques de sécurité, de confidentialité, de performance et architecturaux
• Coordonner plusieurs agents ou outils sans perdre le contrôle
• Expliquer et défendre les décisions techniques

La prochaine génération de formations pour développeurs évaluera donc moins la capacité de l'étudiant à produire de grandes quantités de code et davantage sa capacité à comprendre, diriger, vérifier et améliorer les systèmes logiciels.

Le Changement Central : De la Production de Code au Jugement d'Ingénierie

Les agents de codage ne sont pas de simples auto-complétions plus rapides

Les assistants de codage traditionnels suggèrent une ligne, une fonction ou un petit bloc de code. Les agents de codage autonomes opèrent à une échelle plus large. Ils peuvent travailler sur plusieurs fichiers, invoquer des outils de développement, exécuter des tests, inspecter la documentation et progresser à travers plusieurs étapes.

Cela modifie l'unité de travail. Le flux de travail du développeur ressemble de plus en plus à ceci :

1. Comprendre le problème utilisateur ou métier.
2. Définir le comportement souhaité.
3. Diviser le travail en tâches plus petites.
4. Assigner une tâche appropriée à un agent.
5. Inspecter le plan de l'agent.
6. Laisser l'agent implémenter dans un environnement contrôlé.
7. Exécuter des tests et des contrôles de sécurité.
8. Examiner le résultat.
9. Demander des modifications ou réviser la conception.
10. Approuver, fusionner et surveiller le logiciel.

La personne qui ignore les étapes de planification et de révision peut toujours produire du code, mais ne peut pas produire de manière fiable un produit digne de confiance.

Les limites de la production de code brut

La production de code brut devient une mesure de compétence moins pertinente car un agent peut générer rapidement une grande quantité de code plausible. En même temps, les agents continuent de rencontrer des difficultés avec l'évolution logicielle à long terme, les modifications multi-fichiers, les exigences peu claires et le maintien du comportement malgré des modifications répétées. Une étude comparative de 2025 a révélé un écart substantiel entre la performance des agents pour la résolution de problèmes isolés et les tâches plus complexes d'évolution logicielle à long terme. (arxiv.org)

Cela crée une distinction éducative importante :

• Un étudiant capable de générer du code ne le comprend pas forcément.
• Un étudiant capable d'expliquer, de tester, de remettre en question et de réparer du code fait preuve d'une compétence plus approfondie.

L'objectif éducatif devrait donc devenir le jugement logiciel validé, et non pas simplement la génération de code réussie.

Comment les Curricula S'Adaptent

Les programmes universitaires s'orientent vers la compréhension et la vérification

Le rapport Computer Science Curricula 2023 de l'ACM, de l'Institute of Electrical and Electronics Engineers Computer Society et de l'Association for the Advancement of Artificial Intelligence a anticipé que l'intelligence artificielle générative modifierait l'enseignement de la programmation. Ses directives suggèrent que les étudiants devront davantage se concentrer sur la lecture, la compréhension, la vérification, l'édition, la modification, l'adaptation et le test de code. Il identifie également la décomposition des problèmes comme un domaine susceptible de devenir plus important. (csed.acm.org)

La même directive souligne un point crucial : même lorsqu'un agent écrit le programme, l'humain reste responsable de déterminer si le programme est correct. Cela signifie que l'enseignement de la programmation ne peut pas se limiter à la rédaction d'instructions (prompts). Les étudiants ont besoin d'une compréhension technique suffisante pour évaluer le résultat.

Le rapport anticipe également des changements dans l'enseignement de l'ingénierie logicielle, y compris une utilisation accrue de l'intelligence artificielle pour la génération de code, le débogage, l'analyse statique et la revue de code. L'utilisation efficace de ces outils exige des compétences plus solides en conception et en compréhension de code, et non des compétences moindres. (csed.acm.org)

L'accréditation commence à récompenser des résultats d'ingénierie plus larges

Les critères d'accréditation actuels pour l'informatique de l'Accreditation Board for Engineering and Technology mettent déjà l'accent sur :

• L'analyse de problèmes informatiques complexes
• La conception et l'évaluation de solutions informatiques
• La communication professionnelle
• La responsabilité légale et éthique
• La sécurité et la confidentialité
• Les impacts sociaux de l'informatique
• Un projet complet ou une composante expérientielle (abet.org)

Ces résultats sont bien adaptés à un environnement de développement basé sur des agents car ils mesurent le jugement et la responsabilité plutôt que le nombre de frappes au clavier.

Au 26 juillet 2026, les modifications proposées par l'Accreditation Board for Engineering and Technology pour le cycle 2026-2027 incluent des critères de programme d'intelligence artificielle supplémentaires et l'exigence que les diplômés soient capables d'appliquer les théories, modèles et techniques d'intelligence artificielle à des problèmes complexes. Les changements proposés attendaient toujours leur adoption finale et devaient prendre effet après la réunion de l'automne 2026, avec une première application durant le cycle d'examen 2027-2028. (abet.org)

La direction probable est claire : les programmes devront montrer que les étudiants peuvent construire et évaluer des systèmes, et non pas simplement réaliser des exercices de programmation isolés.

De nouveaux cours enseignent l'utilisation des agents comme une discipline d'ingénierie

Plusieurs cours universitaires récents illustrent la tendance émergente.

Le cours de l'Université du Maryland de 2025 sur l'utilisation efficace des assistants de codage et des agents d'intelligence artificielle couvrait les outils capables d'invoquer des systèmes de build, d'exécuter des tests et de corriger les erreurs. Il abordait également la maintenabilité, l'architecture, la conception d'interfaces de programmation d'applications (API), l'efficacité, l'évolutivité, la sécurité, l'intégration continue, la revue de code, les agents asynchrones et la revue de code automatisée. (cs.umd.edu)

L'Université de Pennsylvanie a proposé un cours d'informatique de deuxième année axé sur le développement logiciel piloté par l'intelligence artificielle. Les sujets proposés incluent la délégation de tâches de codage, la conception modulaire, les tests évolutifs, la gestion des risques, la reproductibilité, la collaboration et l'éthique. (seas.upenn.edu)

Le cours de l'Université du Michigan de l'automne 2026, Applied Agentic Software Engineering, est encore plus explicite. Il est organisé en trois phases :

1. Utiliser efficacement les agents de codage
2. Construire un agent en utilisant une interface de programmation d'application (API) de grand modèle linguistique
3. Concevoir, évaluer et déployer un orchestrateur d'agents

Le cours utilise des projets, des laboratoires, des démonstrations et des validations plutôt que des examens traditionnels. Il stipule que la notation récompensera la compréhension plutôt que le résultat et demande aux étudiants d'expliquer pourquoi un agent a échoué et comment réparer le système environnant. (eecs498-aase.github.io)

Il s'agit d'un changement de conception significatif. Le cours n'enseigne pas aux étudiants à produire du code plus rapidement. Il leur enseigne à devenir des superviseurs techniques de systèmes qui produisent du code.

Comment les Bootcamps Évoluent

Les bootcamps s'adaptent plus rapidement que de nombreux programmes traditionnels car leurs curricula sont étroitement liés aux exigences de l'emploi. Cependant, la qualité de l'adaptation varie.

Le modèle du bootcamp dédié à l'intelligence artificielle

Le bootcamp Artificial Intelligence Software Development actuel du Wagon combine le développement full-stack avec l'intégration de l'intelligence artificielle. Son programme publié inclut le codage assisté par l'IA, l'intégration de grands modèles linguistiques, le déploiement en production, la génération augmentée de récupération (retrieval-augmented generation) et les agents autonomes d'IA. (lewagon.com)

Ce modèle traite l'intelligence artificielle comme un fil conducteur du programme plutôt que comme une seule leçon optionnelle. Les étudiants doivent apprendre les deux :

• Comment fonctionnent les systèmes logiciels conventionnels
• Comment utiliser les outils d'intelligence artificielle pour construire et opérer ces systèmes

Cette combinaison est importante. Un apprenant qui ne sait qu'opérer un agent peut être incapable de reconnaître une architecture défectueuse. Un apprenant qui ne connaît que la programmation conventionnelle peut ne pas être préparé aux flux de travail de développement modernes.

Le modèle « ajouter une unité d'intelligence artificielle »

Le bootcamp d'ingénierie logicielle de Springboard conserve une base conventionnelle en développement web, interfaces de programmation d'applications, développement front-end, développement back-end et projets full-stack, tout en ajoutant une unité d'intelligence artificielle axée sur l'ingénierie de prompts et la collaboration avec des outils génératifs. (springboard.com)

Ce modèle est utile pour les apprenants qui ont d'abord besoin de solides fondamentaux en programmation. Il reflète également une réalité pratique : de nombreux étudiants ne devraient pas commencer par construire des agents autonomes. Ils devraient d'abord apprendre comment les logiciels fonctionnent, comment utiliser le contrôle de version, comment lire les messages d'erreur et comment tester un programme.

La faiblesse est qu'un module court d'ingénierie de prompts peut devenir trop superficiel. Un programme sérieux de l'ère des agents devrait enseigner plus que comment demander du code. Il devrait enseigner :

• Comment créer un fichier de contexte de dépôt
• Comment rédiger une spécification technique
• Comment définir les limites des tâches
• Comment restreindre les permissions d'un agent
• Comment inspecter les plans d'agent
• Comment évaluer les tests générés
• Comment détecter les problèmes de sécurité
• Comment comparer des conceptions alternatives
• Comment documenter l'implication d'un agent

Ce que les étudiants de bootcamps devraient rechercher

Les futurs étudiants devraient se demander si un programme évalue les points suivants :

• Les étudiants peuvent-ils expliquer le code qu'ils n'ont pas tapé eux-mêmes ?
• Les étudiants révisent-ils et réparent-ils les résultats d'agent défectueux ?
• Les tests, la sécurité et la maintenabilité sont-ils évalués ?
• Y a-t-il une démonstration en direct ou une soutenance technique ?
• Les étudiants maintiennent-ils un historique de projet sous contrôle de version ?
• Les étudiants apprennent-ils à travailler sans agent lorsque nécessaire ?
• Le programme enseigne-t-il la découverte de produit et l'analyse des exigences ?
• Les compétences spécifiques aux outils sont-elles équilibrées avec des principes d'ingénierie durables ?

Un programme qui annonce « construire une application en une semaine avec l'intelligence artificielle » peut être excellent pour le prototypage rapide, mais ce n'est pas la même chose que de préparer quelqu'un à l'ingénierie logicielle professionnelle.

Comment les Certifications S'Adaptent

Les organismes de certification développent trois grands types de titres.

Certifications de connaissances spécifiques aux outils

La certification GitHub Copilot de Microsoft évalue l'utilisation responsable, les fonctionnalités de Copilot, l'architecture des données, la création de contexte et de prompts, la productivité des développeurs, la confidentialité, les exclusions de contenu et les mesures de protection. L'examen est surveillé, dure cent minutes et peut contenir des composants interactifs. (learn.microsoft.com)

Ce titre reconnaît des connaissances professionnelles utiles. Il peut montrer qu'une personne comprend comment utiliser une plateforme de développement particulière de manière responsable.

Sa limitation est qu'il est fortement lié à un seul produit. Un professionnel qui sait utiliser GitHub Copilot peut toujours manquer de la capacité à décomposer une exigence de produit complexe, à remettre en question un choix architectural ou à examiner un changement sensible à la sécurité.

Certifications de développement d'IA basées sur des plateformes

La certification AWS Certified Generative AI Developer – Professional est plus large. Son guide d'examen inclut l'intégration de modèles de fondation, la gestion des données, la conformité, l'implémentation, les solutions d'intelligence artificielle agentiques, la sécurité, la gouvernance, les tests, le dépannage, la surveillance et l'optimisation. (docs.aws.amazon.com)

Cependant, l'examen est principalement à choix multiples et à réponses multiples. C'est un test de connaissances substantiel, mais il ne démontre pas pleinement si un candidat peut construire, réviser ou défendre un système fonctionnel. (aws.amazon.com)

Cela illustre un problème plus large : les examens de connaissances sont plus faciles à mettre à l'échelle que les examens de performance. Les organismes de certification peuvent tester la terminologie et les principes de conception efficacement, mais la compétence pratique exige un environnement où les candidats doivent prendre des décisions et gérer l'échec.

Titres basés sur des laboratoires et des projets

Les titres Microsoft Applied Skills offrent un modèle plus prometteur. Ils exigent des apprenants qu'ils accomplissent des tâches interactives alignées sur des travaux réels dans une évaluation basée sur un laboratoire. Microsoft positionne ces titres comme la preuve qu'un candidat peut résoudre de véritables défis cloud et d'intelligence artificielle plutôt que de simplement se souvenir d'informations. (learn.microsoft.com)

Le programme Agentic Artificial Intelligence Program de formation exécutive de l'Université Carnegie Mellon combine enseignement en direct, laboratoires guidés, devoirs, flux de travail multi-agents, évaluation, garde-fous, journalisation (logging), observabilité et un projet de fin d'études (capstone project). (execonline.cs.cmu.edu)

Ces programmes ne sont pas identiques à une certification professionnelle indépendante, mais ils montrent la direction que les titres sont susceptibles de prendre :

• Des évaluations pratiques plus courtes
• Des environnements de développement isolés (sandboxed)
• Des dépôts réalistes
• Des tâches d'évaluation et d'observabilité
• Des systèmes de fin d'études (capstone systems)
• Des explications techniques orales ou enregistrées
• Des preuves d'utilisation responsable des outils

Techniques d'Évaluation qui Mesurent la Compréhension

La meilleure stratégie d'évaluation n'interdit pas les agents pour chaque devoir. Elle utilise les agents là où ils reflètent la pratique professionnelle et réserve certaines activités pour mesurer la compréhension indépendante.

1. Documents de spécification et de décomposition

Avant d'écrire du code, demander aux étudiants de soumettre :

• Le problème utilisateur
• Les exigences fonctionnelles
• Les exigences non fonctionnelles
• Les hypothèses
• Les contraintes
• Les structures de données
• Les interfaces
• Les critères d'acceptation
• Une décomposition des tâches
• Les risques connus

Le document doit expliquer pourquoi le problème a été divisé en tâches spécifiques.

Cela mesure si l'étudiant comprend le problème avant de demander à un agent de l'implémenter.

2. Points de contrôle de la planification de l'agent

Exiger des étudiants qu'ils montrent le plan proposé par l'agent avant le début de l'implémentation. L'étudiant doit identifier :

• Quelles parties du plan sont acceptables
• Quelles parties sont incomplètes
• Quelles hypothèses sont dangereuses
• Quelles tâches nécessitent une approbation humaine
• Quels tests devraient être ajoutés

La note finale devrait récompenser la qualité du jugement de l'étudiant, et non la longueur du plan de l'agent.

3. Évaluations de revue de code

Donner aux étudiants un dépôt généré par un agent contenant des défauts délibérés. Les défauts peuvent inclure :

• Gestion incorrecte des cas limites
• Authentification non sécurisée
• Mauvaise gestion des erreurs
• Problèmes de performance cachés
• Logique dupliquée
• Interfaces peu claires
• Tests insuffisants
• Violations de la vie privée
• Risques liés aux dépendances

Demander aux étudiants de produire une revue avec des niveaux de gravité, des preuves, des corrections proposées et des tests de régression.

Ceci est plus proche du travail logiciel professionnel que de demander aux étudiants de créer une autre petite application à partir de zéro.

4. Explication et soutenance orale

Un étudiant devrait être capable d'expliquer :

• Ce que fait le système
• Pourquoi l'architecture a été choisie
• Quelles parties ont été générées
• Quelles hypothèses l'agent a faites
• Comment les tests démontrent la correction
• Ce qui pourrait encore échouer
• Quels compromis ont été acceptés

Une courte soutenance orale peut être menée individuellement ou en petits groupes. Elle n'a pas besoin d'être intimidante. Cinq à dix questions ciblées sont souvent suffisantes pour révéler si un étudiant comprend la soumission.

5. Tâches de transfert

Après qu'un étudiant ait terminé un projet assisté par agent, fournir une nouvelle exigence qui ne peut être résolue en répétant simplement la prompt originale.

Par exemple :

• Ajouter une nouvelle source de données
• Modifier l'objectif de performance
• Supporter un format d'entrée inattendu
• Supprimer une dépendance
• Ajouter des contrôles d'accès
• Expliquer un test échoué
• Refactoriser un module sans modifier son comportement

L'étudiant peut utiliser un agent, mais doit expliquer le plan, vérifier les changements et défendre le résultat.

Les tâches de transfert mesurent si l'étudiant a appris une méthode générale plutôt qu'il n'a mémorisé une interaction réussie.

6. Conception de tests et tests adversariaux

Les étudiants devraient être notés sur la qualité de leurs tests, et pas seulement sur le fait que le code généré passe les tests fournis.

Les exigences utiles incluent :

• Écrire des tests de limite
• Créer des tests négatifs
• Tester des entrées invalides
• Tester la récupération après échec
• Vérifier les hypothèses de performance
• Utiliser des tests basés sur les propriétés lorsque cela est approprié
• Tester le comportement sensible à la sécurité
• Expliquer ce qui reste non testé

La question clé n'est pas « Le code a-t-il passé les tests ? » mais « L'étudiant savait-il ce qui devait être testé ? »

7. Historique de version et portfolios de processus

Un portfolio de projet peut inclure :

• Spécification initiale
• Décomposition des tâches
• Plans d'agent
• Principales prompts ou instructions
• Commits
• Résultats des tests
• Commentaires de revue
• Approches échouées
• Modifications de conception
• Réflexion finale

Un portfolio de processus ne devrait pas devenir une exigence de soumettre chaque ligne de conversation privée. Un enregistrement représentatif est souvent plus utile qu'une transcription énorme.

Le cours de programmation de Princeton de 2025, par exemple, autorisait les outils d'intelligence artificielle générative mais exigeait des étudiants qu'ils décrivent leur utilisation dans un fichier README par un résumé représentatif plutôt qu'une transcription exhaustive. (cs.princeton.edu)

8. Évaluation par les pairs structurée

La revue par les pairs transforme les étudiants de simples producteurs de code en critiques de code. Des recherches préliminaires suggèrent que l'évaluation par les pairs basée sur des rubriques peut approcher l'évaluation de l'instructeur avec une précision modérée tout en développant la pensée évaluative et l'engagement. (arxiv.org)

Les étudiants devraient être tenus de justifier leurs commentaires avec des preuves. « Ce code est mauvais » n'est pas une revue. « Cette fonction effectue une requête de base de données à l'intérieur d'une boucle, créant un problème de performance probable lorsque la collection s'agrandit » est une revue.

9. Problèmes de prompt et de spécification

Les Prompt Problems sont des exercices de programmation où les étudiants écrivent des instructions en langage naturel qui amènent un système d'intelligence artificielle à générer du code satisfaisant une spécification. L'approche enseigne explicitement aux étudiants à communiquer les exigences computationnelles aux systèmes générateurs de code. (arxiv.org)

Cela peut être utile, mais cela ne devrait pas être la seule méthode d'évaluation. Une étude de 2026 impliquant plus de neuf cents étudiants a révélé que les erreurs courantes incluaient l'omission de détails importants dans les prompts. Lorsque le code généré échouait, les étudiants se concentraient souvent sur la clarification de leur intention plutôt que sur le traçage du code ou l'examen des cas de test. (arxiv.org)

La prompting peut donc révéler des compétences en décomposition et en communication, mais elle doit être combinée avec la lecture de code, les tests, le débogage et la revue.

Une structure d'évaluation modèle

Un projet pratique pourrait utiliser la pondération suivante :

Cette structure récompense toujours un produit fonctionnel, mais elle empêche un étudiant de recevoir une note élevée simplement parce qu'un agent a produit une grande base de code.

Intégrité Académique dans les Travaux Assistés par Agent

Les interdictions générales et l'utilisation illimitée sont toutes deux inadéquates

Une interdiction générale peut être appropriée pour une évaluation fondamentale spécifique, surtout lorsque l'objectif d'apprentissage est la pratique indépendante de la programmation. Cependant, une interdiction universelle est de plus en plus difficile à appliquer et peut empêcher les étudiants d'apprendre des outils qu'ils rencontreront dans leur travail professionnel.

L'utilisation illimitée est également inadéquate. Si les étudiants peuvent soumettre un travail produit par un agent sans explication, l'évaluation pourrait mesurer l'accès à un outil plutôt que l'apprentissage.

L'approche la plus solide est une politique explicite, au niveau de chaque devoir.

Trois modes de politique utiles

Mode un : Agent interdit

À utiliser pour :

• Les examens
• Les exercices de programmation fondamentaux
• Les démonstrations de débogage individuelles
• Les exercices d'algorithmes fondamentaux
• Les évaluations conçues pour mesurer le rappel ou l'implémentation sans aide

Le cours Principles of Imperative Computation de Carnegie Mellon interdit les outils d'intelligence artificielle pour toute partie des travaux notés, y compris la génération de solutions, l'explication de solutions, le formatage de code et la génération de cas de test. (cs.cmu.edu)

Mode deux : Agent restreint

À utiliser lorsque les étudiants peuvent demander :

• Des explications de concepts
• De l'aide pour la documentation
• L'interprétation de messages d'erreur
• La clarification de bibliothèques ou d'interfaces de programmation d'applications
• Du brainstorming
• La critique d'une conception créée par l'étudiant
• Un refactoring mineur

Les cours systèmes de Carnegie Mellon autorisent les outils d'intelligence artificielle pour la compréhension des interfaces de programmation d'applications, des bibliothèques, des frameworks, du code fourni et des messages d'erreur, tout en interdisant les demandes de solutions d'affectation partielles ou complètes. (cs.cmu.edu)

Mode trois : Agent autorisé avec divulgation

À utiliser pour des projets d'ingénierie logicielle réalistes. Exiger des étudiants qu'ils divulguent :

• Quels outils ont été utilisés
• Quelles tâches ont été déléguées
• Si le code généré a été copié, modifié ou réécrit
• Comment le résultat a été testé
• Ce que l'étudiant a appris
• Quelles parties de la conception restent sous la responsabilité de l'étudiant

Les directives d'intégrité académique de Princeton stipulent que l'utilisation autorisée de l'intelligence artificielle doit toujours être divulguée et que représenter un résultat généré comme le sien ou ne pas divulguer son utilisation peut constituer une violation d'intégrité. (scholarlyintegrity.princeton.edu)

La Harvard Graduate School of Education autorise de même des utilisations telles que la clarification, le brainstorming et l'exploration, tout en interdisant aux étudiants de soumettre des travaux générés par l'intelligence artificielle comme les leurs. Elle exige également une documentation de l'utilisation autorisée et avertit que les étudiants restent responsables de l'exactitude, de la confidentialité, des droits d'auteur et des biais. (registrar.gse.harvard.edu)

Une déclaration de divulgation pratique

Un cours peut fournir un modèle simple :

J'ai utilisé [nom de l'outil] pour [la planification, le débogage, la génération de code, les tests, la documentation ou la revue]. J'ai délégué [tâches spécifiques]. J'ai examiné et modifié le résultat, testé le système qui en a résulté, et je reste responsable de l'exactitude, de la sécurité et de l'originalité de la soumission.

Les étudiants ne devraient pas être tenus de divulguer une simple correction orthographique de la même manière qu'une implémentation déléguée. Les politiques devraient distinguer l'assistance mineure de la contribution cognitive ou technique substantielle.

Confidentialité et égalité d'accès

Les institutions devraient fournir des outils approuvés ou des alternatives. Les étudiants ne devraient pas être tenus de télécharger des travaux confidentiels, des informations personnelles, des recherches non publiées ou du code propriétaire sur des systèmes publics.

Les directives de l'UNESCO appellent à une approche centrée sur l'humain qui tienne compte de la confidentialité, de la sécurité, de l'équité, de l'inclusion et de la préparation institutionnelle. (unesco.org)

Les cours devraient également prendre en compte les étudiants qui ne peuvent pas se permettre plusieurs outils payants. Un cours équitable peut :

• Fournir un outil institutionnel partagé
• Proposer une alternative locale ou open-source
• Concevoir des devoirs qui ne dépendent pas d'un seul fournisseur
• Évaluer le raisonnement plutôt que l'accès au modèle le plus puissant
• Permettre des parcours sans agent pour chaque résultat d'apprentissage essentiel

Méthodes Pratiques pour Intégrer les Agents de Manière Productive

Utiliser un dépôt contrôlé

Donner aux étudiants un dépôt contenant :

• Un fichier README clair
• Une base de code petite mais réaliste
• Des tests automatisés
• Un flux de travail d'intégration continue
• Une liste de problèmes connus
• Un guide de style
• Une liste de contrôle de sécurité
• Un journal des modifications

Cela rend l'utilisation des agents observable et offre aux étudiants quelque chose de plus réaliste qu'un simple exercice de codage vide.

Exiger un plan avant l'implémentation

Les étudiants ne devraient pas commencer par demander à un agent de « construire toute l'application ». Exiger une séquence :

1. Demander à l'agent d'inspecter le dépôt.
2. Demander un résumé de l'architecture.
3. Demander les risques et les informations manquantes.
4. Écrire le propre plan de tâches de l'étudiant.
5. Approuver une petite tâche d'implémentation.
6. Revoir les changements résultants.
7. Exécuter des tests avant de continuer.

Cela enseigne la délégation contrôlée plutôt que la délégation aveugle.

Utiliser une équipe d'agents avec des rôles clairs

Un modèle d'orchestration simple peut inclure :

• Planificateur : propose la décomposition des tâches
• Implémenteur : modifie le code
• Testeur : crée et exécute les tests
• Réviseur : recherche les défauts et les risques
• Évaluateur humain : approuve ou rejette les changements

Les étudiants devraient apprendre que l'ajout de plus d'agents n'améliore pas automatiquement la qualité. Plus d'agents peuvent créer des instructions contradictoires, des efforts dupliqués, des coûts accrus et une responsabilité floue.

L'objectif pédagogique n'est pas de construire le plus grand système multi-agents. Il est de choisir le flux de travail le plus simple qui produit des résultats fiables.

Intégrer des points d'approbation humaine

Exiger une approbation explicite avant qu'un agent ne puisse :

• Modifier l'authentification
• Modifier les schémas de données
• Ajouter des dépendances
• Accéder aux systèmes de production
• Modifier la configuration de déploiement
• Supprimer des fichiers
• Fusionner une pull request

Cela enseigne aux étudiants que l'autonomie doit être limitée par des permissions et une revue.

Noter délibérément les échecs

Les agents sont les plus éducatifs lorsqu'ils échouent de manière informative. Les instructeurs devraient inclure :

• Des exigences ambiguës
• Des contraintes conflictuelles
• Des tests incomplets
• Des opérations sensibles à la sécurité
• Une documentation trompeuse
• Des tests instables (flaky tests)
• Des limites de performance
• Un changement qui semble correct mais qui casse une autre fonctionnalité

La tâche de l'étudiant est de diagnostiquer l'échec et d'améliorer le processus.

Un Cadre de Compétences pour 2026 à 2031

Le cadre suivant est conçu pour rester utile même si les outils spécifiques changent.

Domaine un : Fondamentaux techniques et littératie du code

Un développeur compétent peut :

• Lire du code inconnu
• Expliquer le flux de contrôle et le flux de données
• Comprendre les interfaces et les dépendances
• Analyser la complexité algorithmique
• Utiliser le contrôle de version
• Déboguer sans dépendre entièrement d'un agent

Preuve : explication de code, tâche de débogage manuel, critique de conception et exercice de transfert individuel.

Domaine deux : Cadrage et décomposition du problème

Un développeur compétent peut :

• Clarifier les objectifs utilisateur
• Identifier les contraintes et les hypothèses
• Séparer les exigences essentielles des exigences optionnelles
• Diviser le travail en tâches testables indépendamment
• Définir les critères d'acceptation
• Reconnaître quand une tâche est trop vaste pour une délégation fiable

Preuve : spécification, graphe de tâches, registre des risques et explication des choix de décomposition.

Domaine trois : Direction des agents et ingénierie du contexte

Un développeur compétent peut :

• Fournir un contexte de dépôt pertinent
• Donner des instructions précises
• Définir les limites et les permissions
• Choisir quand utiliser un agent et quand ne pas en utiliser un
• Comparer des plans alternatifs
• Récupérer lorsque l'agent suit une mauvaise interprétation

Preuve : points de contrôle de planification, enregistrements d'interaction représentatifs et une tâche de révision en direct.

Domaine quatre : Vérification et revue

Un développeur compétent peut :

• Inspecter le code généré
• Concevoir des tests significatifs
• Identifier les hypothèses cachées
• Examiner les risques de sécurité et de confidentialité
• Évaluer la maintenabilité
• Expliquer ce que les tests ne prouvent pas

Preuve : revue de code, tests adversariaux, exercice de détection de défauts et soutenance orale.

Domaine cinq : Orchestration et opérations

Un développeur compétent peut :

• Coordonner les outils de planification, d'implémentation, de test et de revue
• Utiliser des points de contrôle et des étapes d'approbation humaine
• Suivre les coûts, le temps et le comportement des outils
• Maintenir des flux de travail reproductibles
• Observer les échecs et améliorer le système
• Décider si plusieurs agents apportent une valeur ajoutée

Preuve : flux de travail d'orchestration fonctionnel, journaux, rapport d'évaluation et analyse des coûts ou des performances.

Domaine six : Conception de produits et de systèmes

Un développeur compétent peut :

• Sélectionner un niveau d'automatisation approprié
• Concevoir des systèmes modulaires
• Équilibrer vitesse, qualité, coût et risque
• Relier les décisions techniques aux résultats utilisateur
• Reconnaître quand une solution simple sans agent est meilleure

Preuve : note de produit, enregistrement de décision d'architecture, prototype et démonstration centrée sur l'utilisateur.

Domaine sept : Pratique professionnelle responsable

Un développeur compétent peut :

• Divulguer l'assistance de l'intelligence artificielle
• Protéger les informations privées et propriétaires
• Respecter les obligations de droit d'auteur et de licence
• Identifier les biais et les risques de fiabilité
• Communiquer l'incertitude
• Accepter la responsabilité du système final

Preuve : déclaration de divulgation, évaluation des risques, revue de confidentialité et présentation professionnelle.

Niveaux de compétence suggérés

D'ici 2031, un titre professionnel devrait démontrer une progression à travers ces niveaux plutôt que de simplement confirmer une familiarité avec un outil logiciel particulier.

Recommandations pour les Différentes Parties Prenantes

Universités

• Ajouter des modules d'ingénierie logicielle conscients des agents aux cours existants.
• Préserver la programmation et les algorithmes fondamentaux.
• Remplacer certains devoirs de génération de code par des tâches de revue et de transfert.
• Exiger des étudiants qu'ils expliquent et défendent les travaux importants.
• Former les professeurs aux outils agents, à la conception d'évaluation, à la confidentialité et aux politiques d'intégrité.
• Construire des dépôts partagés et des environnements de sandbox.

Bootcamps

• Enseigner le développement conventionnel et le développement assisté par agent ensemble.
• Faire des tests, de l'architecture et de la sécurité des éléments centraux du curriculum.
• Exiger des projets de portfolio avec des enregistrements de processus.
• Ajouter des démonstrations techniques en direct.
• Enseigner la découverte de produit et la rédaction des exigences.
• Éviter de promettre que la seule prompting crée des ingénieurs prêts à l'emploi.

Organismes de certification

• Accroître l'utilisation d'évaluations basées sur des laboratoires.
• Inclure la revue de code, les tests, le débogage et l'analyse des menaces.
• Utiliser des dépôts réalistes plutôt que des questions à choix multiples isolées.
• Tester le jugement indépendant de l'outil.
• Ajouter de courtes explications orales ou des démonstrations enregistrées.
• Actualiser le contenu fréquemment sans rendre le titre dépendant de l'interface d'un fournisseur.

Instructeurs

• Énoncer exactement ce qui est autorisé pour chaque évaluation.
• Concevoir les devoirs en fonction du résultat d'apprentissage visé.
• Donner aux étudiants des outils approuvés ou des alternatives équivalentes.
• Évaluer le processus, le raisonnement et la vérification.
• Utiliser les journaux comme preuve, pas comme la seule preuve.
• Éviter de se fier aux logiciels de détection d'intelligence artificielle comme principal mécanisme d'intégrité.

Apprenants et créateurs de produits

• Apprendre suffisamment de programmation conventionnelle pour lire et remettre en question le code généré.
• Commencer par un petit produit plutôt qu'une grande application vague.
• Rédiger la spécification avant d'ouvrir un agent.
• Déléguer un problème à la fois.
• Examiner chaque changement et tester chaque hypothèse.
• Tenir un registre des décisions importantes.
• Traiter l'agent comme un collaborateur junior rapide, et non comme un expert incontestable.

La Première Prochaine Étape

Pour quelqu'un qui débute un parcours de création de produit, la première étape la plus utile est :

Choisir un petit problème utilisateur et rédiger une spécification d'une page avant de demander à un agent d'écrire du code.

Inclure :

• Qui est l'utilisateur
• Quel problème ils ont
• Ce que la première version doit faire
• Ce qu'elle ne doit pas faire
• Trois tests d'acceptation
• Une préoccupation importante en matière de sécurité ou de confidentialité
• Trois petites tâches d'implémentation

Ensuite, demander à l'agent de réviser la spécification et d'identifier les exigences manquantes, et non de construire le produit entier.

Après avoir corrigé la spécification, ne déléguer que la première tâche. Revoir le plan proposé, inspecter les changements, exécuter les tests et noter ce que l'agent a mal fait.

Cet unique exercice enseigne la leçon la plus importante de l'ère des agents : la qualité du résultat dépend moins de la quantité de code que l'agent peut produire que de la clarté avec laquelle l'humain définit, supervise et évalue le travail.

Conclusion

L'éducation des développeurs s'oriente vers un nouvel équilibre.

Les étudiants devront toujours écrire du code, surtout lors de l'apprentissage des concepts fondamentaux. Mais la compétence professionnelle sera de plus en plus démontrée par la décomposition des problèmes, la spécification, la compréhension du code, la revue, les tests, l'orchestration, le jugement produit et l'utilisation responsable des systèmes autonomes.

Les programmes d'études les plus solides ne traiteront pas les agents de codage comme des machines à tricher ou des tuteurs magiques. Ils les traiteront comme des outils d'ingénierie puissants mais faillibles. Les étudiants apprendront quand les utiliser, comment les contraindre, comment évaluer leur production et comment assumer la responsabilité du système final.

Le développeur le plus durable des cinq prochaines années ne sera pas celui qui pourra produire le plus de code à la main ou générer la plus longue prompt. Ce sera la personne capable de transformer un objectif flou en un processus fiable, de guider plusieurs outils vers cet objectif, de détecter rapidement les échecs et d'expliquer pourquoi le logiciel résultant mérite d'être fiable.