- La plupart des outils d’IA actuels ne reflètent pas les processus d’apprentissage centrés sur l’humain (rappel, exécution, répétition collective) — c’est au final une conception à rebours qui détruit la boucle de progression des humains comme de l’IA
- Les humains n’apprennent pas un savoir, mais un "processus", et innovent grâce à une répétition collective et cumulative. Pourtant, la plupart des outils d’IA suivent le schéma « clic sur un bouton → l’IA s’occupe de tout », ce qui supprime la boucle de rappel et d’apprentissage pilotée par l’humain
- Un bon outil d’IA doit encourager la participation active et le rappel de l’utilisateur dans les étapes “Expliquer → Démontrer → Guider → Renforcer (Explain, Demonstrate, Guide, Enhance)”, et viser non pas l’automatisation, mais l’amplification
- Exemple : dans les outils d’observabilité/rétablissement, l’IA ne devrait pas agir immédiatement, mais jouer un rôle qui stimule la réflexion et l’apprentissage humains à chaque étape : explication du processus, orientation des actions, guide de résolution du problème, suggestions d’amélioration après coup, etc.
- Si ce modèle centré sur l’humain s’installe, il devient possible de créer une boucle de rétroaction positive où la croissance collective des connaissances et la qualité de l’IA se renforcent mutuellement, ouvrant la voie à une innovation sur l’ensemble des outils système
Introduction : le problème fondamental de l’apprentissage humain et de l’outillage IA
- Les outils d’IA sont conçus dans une direction inefficace et à rebours, au lieu de soutenir la collaboration et l’apprentissage humains
- Les outils sont pensés non pour renforcer les capacités humaines, mais d’une manière qui entrave la pensée critique et la résolution de problèmes
- Cette situation produit déjà des effets pervers visibles, et il faut changer de cap vers une approche plus efficace
Limites des outils d’IA actuels : un développement à rebours
- Aujourd’hui, la majorité des outils d’IA suivent le schéma suivant
- Cliquer sur un bouton IA → obtenir un résultat immédiat comme par magie
- Affichage des données et suggestions de l’IA
- Prompt simple et exécution automatique
- Cette approche court-circuite les boucles d’apprentissage essentielles : définition du problème, mémoire, rappel, apprentissage du processus, transmission des connaissances, amélioration itérative
- L’IA essaie de remplacer les principaux atouts humains, alors qu’elle est elle-même fragile sur ce terrain
- Résultat : régression des capacités humaines de réflexion et de résolution de problèmes → impossibilité de produire des données de qualité (ce qui freine aussi les progrès de l’IA) → formation d’un cercle vicieux
Comment les humains apprennent-ils ?
- Selon la théorie de la Retrieval Practice, les humains n’apprennent pas en recevant passivement de l’information, mais grâce au rappel actif
- Ce n’est pas la simple mémorisation, mais le fait de “faire remonter” l’information depuis le cerveau qui produit un véritable effet d’apprentissage
- Dans l’apprentissage, l’essentiel est l’acquisition du processus plus que le savoir lui-même
- Par exemple, pour apprendre la pâtisserie, il est plus efficace d’apprendre la procédure pour faire un gâteau que de mémoriser les ingrédients
- C’est pourquoi une conception centrée sur les processus concrets est mieux adaptée aux outils collaboratifs
Le principe de l’innovation et de la croissance collective
- L’essence de l’innovation ne vient pas d’un individu qui invente seul une nouvelle technologie, mais de l’accumulation collective de petites améliorations itératives
— l’essentiel n’est pas la création géniale d’une poignée d’individus, mais le processus par lequel plusieurs personnes ajoutent, superposent et améliorent à partir d’un savoir existant
- Les humains sont moins optimisés pour l’innovation totalement indépendante que pour l’imitation, la répétition et la transformation de cas existants
- Les théories de l’apprentissage collectif fondé sur le cerveau montrent que cette forme d’innovation collective convient fondamentalement à l’être humain
- Plutôt que de séparer résolution de problèmes et innovation, il faut voir que la capacité à résoudre des problèmes, la transmission des connaissances et l’apprentissage collectif sont le moteur même de l’innovation
- Les éléments clés sont un apprentissage centré sur les processus, un effort d’un niveau approprié, la répétition et le renforcement collectifs, et une IA qui assiste l’humain
- Les outils d’IA doivent être des “assistants de réflexion” pour les humains, et non des entités qui jugent à leur place et les remplacent
Concevoir correctement les interactions avec l’IA
- L’IA se compare moins à un collègue ou à un stagiaire qu’à un formateur très distrait
- Son but est d’aider l’utilisateur à apprendre par lui-même, et à apprendre comment apprendre
- Il faut la concevoir comme un renforcement d’un processus pédagogique efficace (EDGE : Explain, Demonstrate, Guide, Enhance)
- Expliquer (Explain) : orientation dans le processus, indication des étapes manquantes, etc. (et non pas simplement « cliquez sur ce bouton »)
- Suggérer les étapes oubliées
- Fournir et commenter un guide du processus
- Mettre l’accent sur le fait que l’humain rappelle et exécute lui-même le processus
- Mauvais exemple : fournir immédiatement un bouton « exécuter », des info-bulles d’erreur, etc., au point de laisser de côté le processus de rappel
- Démontrer (Demonstrate) : transformation de requêtes, démonstration UI, démos interactives, etc. ; non pas une exécution automatique directe, mais une logique centrée sur l’incitation à participer
- Convertir une requête en langage naturel vers la syntaxe de requête du système
- Aider à explorer l’interface UI (en dirigeant immédiatement vers l’écran pertinent sur demande)
- Fournir une courte démo de 15 secondes ou un tutoriel interactif
- Éviter l’« exécution automatique » : baisse de confiance, impossibilité d’ajustements fins, dégradation des capacités humaines
- L’IA doit aussi utiliser comme matière d’apprentissage les données ajoutées et les traces de rappel humain (pairing, mentoring, etc.)
- Guider (Guide) : susciter des questions, discuter des zones de blocage, établir un plan d’action, dans une logique de questionnement/vérification socratique
- Si l’utilisateur fournit un plan, proposer la prochaine action et des indications
- Indiquer la documentation nécessaire, les responsables du code, les ressources liées
- Encourager les modèles d’observation/apprentissage et la mise par écrit
- Vérifier les réponses, croiser les informations, confirmer la clarté
- Mauvais exemple : apporter une aide sans faire émerger la réponse, fournir trop d’informations non demandées, adopter une posture autoritaire, ou permettre d’abuser du bouton « continuer »
- L’assistance doit rester dans les limites qui n’entravent pas la répétition du raisonnement rationnel humain
- Renforcer (Enhance) : proposer des améliorations après l’action, apprendre les motifs récurrents, transformer les traces du terrain en postmortem — autant de micro-déclencheurs d’apprentissage
- Proposer des améliorations progressives juste après ou pendant l’action
- Exposer dynamiquement des raccourcis/fonctionnalités supplémentaires pour les tâches répétitives
- Suggérer des améliorations du processus lui-même : amélioration du pipeline d’infrastructure, modification des alertes, recommandation d’une meilleure instrumentation lorsqu’on s’appuie sur l’intuition, etc.
- Transformer les notes après incident en support d’apprentissage, et favoriser le micro-apprentissage par l’observation
- Maintenir le hub de raisonnement humain et introduire naturellement des prompts de renforcement du rappel plutôt qu’une optimisation automatique
- Il faut surtout solidifier, à chaque étape, une structure dans laquelle l’humain rappelle, choisit et exécute, l’IA se concentrant sur son rôle d’amplificateur
- En s’appuyant sur des cas réels (gestion d’incidents, outils d’observabilité), l’article explique pour chaque étape des exemples d’interactions IA de qualité et des antipatterns
Principes généraux
- Renforcer en continu l’apprentissage humain
- Favoriser le travail d’équipe : collaboration collective et partage d’information
- Au lieu d’une automatisation « case vide → bonne réponse », accélérer la participation au processus et son exécution (sans remplacement direct par l’automatisation)
- Éviter le modèle « résultat immédiat à partir de rien »
- Concevoir non pas des outils à usage sans effort, mais des outils qui demandent un effort et une participation appropriés
- Soutenir l’intégration de l’apprentissage et de l’expérience de l’équipe dans les résultats produits
Bon exemple appliqué à l’écriture de code : une conception “dans le bon sens”, pas à rebours
- Il ne s’agit pas de faire générer directement du code par l’IA, mais de suivre plutôt :
- rédaction d’un document de cadrage → schéma d’architecture → plan de test → code de test → code stub → génération du code
- Après validation du code, reprendre le processus à rebours pour réviser tests, documentation et architecture
- À chaque étape, il faut accorder de l’importance aux questions et à la vérification (renforcement du rappel), et éviter de ne poser que des questions oui/non lorsque rien ne peut être vérifié
- Une approche de développement fondée sur le rappel produit des données d’apprentissage et de test de haute qualité, et améliore aussi l’apprentissage de l’IA
Extension possible aux fonctions transverses (hors développement, par ex. support client)
- Exemple : en cas d’arrêt de service dû à un incident, l’équipe support client communique avec l’équipe de développement via l’IA
- L’IA fournit un premier brouillon, puis l’équipe de développement le vérifie pour en améliorer l’exactitude
- Flux d’information en temps réel entre plusieurs équipes comme le support et le développement, avec un minimum de charge liée aux changements de contexte
- Les experts clés ne sont pas excessivement interrompus, tout en permettant une communication fluide quand nécessaire
- L’IA peut facilement convertir les réponses techniques contextualisées de l’équipe de développement en explications compréhensibles par le plus grand nombre
- Si une telle structure se met en place, l’apprentissage collectif et l’efficacité de la collaboration, en interne comme en externe, peuvent être maximisés
- Cela peut évoluer vers des outils de support/intégration multi-couches
Conclusion
- Les outils d’IA actuels sont développés à rebours, d’une manière qui affaiblit la capacité humaine de résolution de problèmes et d’apprentissage collectif par la répétition
- Il faut changer de cap pour mettre l’accent sur le renforcement de la collaboration et le soutien de processus pilotés par l’humain
- C’est à cette condition seulement qu’un cercle vertueux de croissance mutuellement amplifiée entre humains et IA devient possible
- Dans la conception des outils, il ne faut pas oublier que l’humain n’est pas simplement “dans la boucle” : l’humain est la boucle
- Il est temps d’introduire une innovation centrée sur l’humain dans les outils système
- Des outils d’IA collaboratifs, centrés sur le processus et conçus pour amplifier sont la clé de l’innovation
1 commentaires
Avis Hacker News
Cet article est un peu confus. Weakly semble parler d’un agent de codage plus passif, centré sur le conseil, comme la méthode qu’antirez disait apprécier en 2025, mais traite en réalité d’un agent chargé d’enquêter sur des problèmes opérationnels et de les résoudre. L’argument de Weakly, c’est que l’agent devrait se comporter comme Clippy, en se limitant à donner des conseils et en laissant le volant à l’humain. Mais je ne vois pas bien l’intérêt d’obliger une personne à fouiller les logs, repérer des anomalies et formuler des hypothèses. Tout comme l’ordinateur joue mieux aux échecs, l’IA est fondamentalement mieux outillée que l’humain pour ce genre de tâche. Weakly semble tracer une frontière nette entre le conseil et l’action réelle, mais je ne pense pas que cette frontière soit la bonne. Bien sûr, il existe des domaines où l’on ne peut pas confier une exécution autonome complète à l’IA (par ex. lancer un
Terraform apply), mais il y en a aussi beaucoup où il n’y a pas vraiment de raison de l’en empêcher. Le but de la gestion d’incident, au final, c’est de résoudre l’incidentIl n’existe toujours pas d’outil d’IA réellement satisfaisant pour résoudre des incidents. Il y a aussi la question de la responsabilité, et une intervention humaine reste indispensable, ne serait-ce que pour garantir la bonne exécution
Le vrai problème, c’est de savoir si l’on veut donner à l’IA un droit d’accès à l’environnement de production réel. Quand on voit des cas récents où une IA a supprimé une base de données malgré l’instruction de ne pas le faire (notamment parce qu’elle ne reconnaît pas toujours correctement les négations comme « not »), la situation pose de vraies inquiétudes en matière de sécurité
Je me demande jusqu’où on peut accorder de l’autonomie à un agent. Si l’on suit les bonnes pratiques DevOps, la plupart des changements ne sont appliqués en production qu’après un commit de code ou une promotion à travers plusieurs environnements. Cela vaut non seulement pour le code applicatif, mais aussi pour l’infrastructure elle-même. Dans ce contexte, je me demande jusqu’où il est acceptable d’autoriser l’exécution autonome d’un agent dans le cadre de la réponse à incident
Je pense aussi qu’il y a une certaine valeur à déboguer soi-même. Surtout si l’objectif est d’améliorer ses compétences en programmation. Pour reprendre l’exemple des échecs, une IA comme Leela ou Stockfish peut analyser bien plus vite et plus profondément, mais la vraie progression vient du fait d’analyser soi-même les positions. Même les joueurs professionnels travaillent régulièrement des exercices tactiques pour entraîner leur cerveau. Je ne sais pas vraiment si l’on apprend plus vite avec l’IA et l’humain ensemble, ou de manière indépendante. Et je suis aussi partagé sur la question de savoir si cette capacité aura encore du sens à l’avenir
Un point important dans les discussions sur la détection d’anomalies et la gestion d’incident, c’est que tous les problèmes ne se valent pas, et qu’un grand nombre peuvent être automatisés dans une certaine mesure. La frontière entre les cas à confier à un processeur cognitif comme une IA et ceux qui exigent l’intervention directe d’un ingénieur humain est essentielle. L’IA est forte pour détecter des motifs à grande échelle, mais pas forcément pour déterminer de façon fiable s’ils sont significatifs. Cela dit, l’humain n’est pas toujours capable non plus de combler ces lacunes
Du point de vue des outils/produits IA, je pense qu’il faut aller vers des "espaces de travail intelligents (Intelligent Workspaces)". Il faut dépasser le simple chatbot
Lien associé
Fondamentalement, l’important est de disposer d’un environnement/plateforme où toutes les configurations, tous les leviers et tout le contrôle restent entre les mains des humains, tout en intégrant étroitement les fonctions IA. C’est bien plus difficile qu’un simple fork de VSCode
Un chatbot est beaucoup plus simple à mettre en œuvre qu’un espace de travail intelligent. Et l’IA fonctionne très bien même sans interaction humaine. J’aimerais voir davantage de façons d’utiliser l’IA via des interfaces autres que le chat
En ce moment, je travaille sur un projet avec Claude Code, et j’aimerais que mon instance puisse collaborer avec celles d’autres développeurs en dialoguant directement avec elles. On peut maintenir la documentation en modifiant
CLAUDE.md, mais ce serait vraiment bien si CC intégrait nativement des fonctions de collaboration en équipe. Si vous avez de bonnes suggestions, je suis preneurJe pense que cet article montre bien pourquoi l’innovation vient souvent d’acteurs extérieurs. On sent très fortement le profil d’un responsable d’ingénierie ou d’un staff engineer issu d’une grande organisation, et cela résonne assez peu avec mon expérience. Si ce style devait devenir la norme en matière d’outillage IA, je crains une forme de stagnation de l’IA, fondée sur certaines hypothèses implicites sur les workflows humains. Cela fait 15 ans que je fais de la R&D sur des applications de ML d’assistance à des experts métier non programmeurs, et je diffère quelque peu des principes de l’auteur. Le fait que nos perspectives soient aussi différentes montre à quel point l’espace de conception est vaste, et qu’il est bien trop tôt pour conclure qu’une approche donnée est la bonne. Personne ne sait encore où ira l’outillage IA
Ce qui m’inquiète toujours dans le codage avec l’IA, c’est la difficulté à maintenir son niveau. Le simple fait de taper soi-même du code (y compris le boilerplate) joue vraiment un rôle d’entraînement à la Mr. Miyagi. C’est grâce à cette répétition que les motifs s’ancrent profondément dans l’esprit, ce qui aide énormément au moment de prendre des décisions de conception de plus haut niveau
Les technologies plus anciennes (écriture, imprimerie, etc.) ont peut-être affaibli l’écriture manuscrite ou la rhétorique, mais elles ont au contraire amplifié notre capacité à penser. L’idée de Steve Jobs du « bicycle for the mind » en est un bon exemple. Mais appliquer cette logique à l’IA est différent : les technologies précédentes levaient surtout des goulots d’étranglement dans la diffusion, alors que l’IA vise directement le processus créatif lui-même. À mes yeux, l’usage de l’IA dans le travail créatif n’est souhaitable que tant qu’il n’entrave pas le développement de ma propre créativité. L’autocontrôle et la conscience de soi des humains ont leurs limites
La nuit ou sous la douche, il m’arrive souvent de ruminer un problème et d’imaginer du « code » dans ma tête. Si les structures du langage n’étaient pas profondément ancrées en moi, ce genre de programmation mentale serait difficile
On trouve des exemples similaires dans la vie quotidienne :
Il fut un temps où l’on soudait des transistors à la main. Mais aujourd’hui, la technologie a tellement progressé qu’il est devenu coûteux de faire les choses soi-même comme avant. À force d’élargir puis de resserrer le champ de ma pensée, il m’arrive encore d’avoir la nostalgie du code. Cela dit, je code toujours beaucoup
« Every augmentation is an amputation » - Marshall McLuhan
C’est aussi pour ça que j’aime énormément Deep Research. Le système commence toujours par poser des questions, ce qui me pousse à mieux définir moi-même ce que je veux apprendre. J’ai l’impression qu’un simple changement d’UX peut faire une grande différence : soit en favorisant l’apprentissage de l’utilisateur, soit au contraire en l’amenant à dépendre de l’outil sans esprit critique
Mais avez-vous vraiment regardé attentivement ces questions ? Deep Research peut être utile, mais parfois j’ai l’impression que ces « questions » ont juste été ajoutées pour faire bien. Souvent, il redemande des choses que j’ai déjà formulées clairement avec soin. Je n’ai pas l’impression que cela aide beaucoup le vrai processus de recherche
En tant que rédacteur technique, je n’utilise pas Deep Research. Au contraire, cela gêne mon travail. Le processus même de recherche, de prise de notes et de synthèse est essentiel pour m’aider à comprendre un sujet en profondeur. Le document final n’est que le résultat de ce processus. Si l’IA fait ce travail à ma place, j’obtiens bien des notes, mais pas le même niveau de compréhension. Lire un document rédigé par l’IA ne remplace pas l’expérience directe
Je pense que cet article se trompe sur le cœur de l’adoption de l’IA. Le but de l’adoption de l’IA n’est pas de rendre les gens plus intelligents, mais d’éliminer les tâches répétitives dans lesquelles la créativité humaine n’est pas récompensée de manière significative, afin d’améliorer la productivité de l’ensemble du processus
D’après mon expérience, la meilleure façon d’utiliser l’IA quand on code est la suivante :
Récemment, j’ai aidé mon père à préparer une présentation. Il avait largement les informations nécessaires, mais comme il n’est pas designer, il avait du mal à rendre ses slides plus élégantes. J’ai testé plusieurs applications IA de génération de diapositives, et même si elles avaient l’air impressionnantes, elles n’aidaient pas vraiment à obtenir les « améliorations de design » qu’un utilisateur attend réellement. Au final, la conclusion a été qu’il valait bien mieux les retravailler à la main
Je suis tout à fait d’accord sur le fait que le flux « commencer par l’architecture et la conception des tests, puis les appliquer au code réel » est 100 % plus efficace. On peut déjà y parvenir en changeant simplement ses habitudes de workflow, même sans outil dédié (même si, bien sûr, des outils spécialisés ou des prompts standardisés seraient encore mieux)
docker-compose. Et les tâches réelles à accomplir sont les suivantes :Les humains sont une espèce extraordinairement douée pour l’itération cumulative, c’est-à-dire l’amélioration continue. C’est pour cela que le brainstorming fonctionne particulièrement bien en groupe. Il existe même en psychologie cognitive des théories « culturelles » de cet apprentissage collectif et cumulatif de l’innovation. On dit souvent que l’on se tient « sur les épaules de géants » : ce n’est pas qu’une belle formule, c’est réellement ainsi que fonctionnent les humains. La créativité, au fond, est une forme de recherche, et même de recherche sociale. Elle ne se développe pas uniquement à l’intérieur du cerveau, mais dans l’interaction entre le cerveau et l’environnement, au niveau social et culturel. C’est pourquoi je ne me demande pas si les LLM « comprennent » vraiment. S’ils savent chercher, produire des idées et les vérifier dans la pratique, cela me suffit. Et je pense aussi que, quel que soit le substrate sous-jacent, c’est la recherche elle-même qui compte le plus. En revanche, selon le substrate, l’espace de recherche accessible peut varier