Le London AI Engineer Summit 2026 était censé être une célébration du progrès. À la place, il a pris des allures de miroir tendu à une profession en pleine crise nerveuse.
Pendant trois jours, début avril, des centaines d’ingénieurs en IA, de constructeurs de plateformes et de chercheurs se sont rassemblés pour partager ce qu’ils avaient appris. Ce qui en est ressorti était un schéma : tout le monde construit avec des agents, personne n’a trouvé comment les contrôler, l’industrie est divisée entre aller vite et réfléchir posément, et la prémisse même selon laquelle l’IA nous rendrait plus productifs s’est inversée vers quelque chose de plus sombre.
Voici ce que nous avons réellement appris.
Pourquoi les ingénieurs en IA codent-ils avec des agents qu’ils ne peuvent pas contrôler ?
La conversation la plus honnête du sommet s’est tenue dans un couloir, pas sur scène. Un ingénieur d’une fintech de taille moyenne décrivait le problème ainsi : « Je lance un prompt, et trois heures plus tard mon agent a réécrit la moitié du code, ajouté des fonctionnalités que je n’ai pas demandées, et consommé 800 £ en calcul. Je ne peux pas quitter mon bureau. »
C’est le FOMAT : Fear of Missing Attention Time. Ce n’est pas une blague — c’est l’angoisse fondamentale de l’ingénierie en IA de 2026.
Le goulot d’étranglement de l’orchestration
Tous au sommet utilisaient des agents. GitHub Copilot, Claude, frameworks agentiques personnalisés — les outils ont mûri. Mais l’orchestration, non. Le fossé entre « j’ai un agent » et « mon agent fait ce que j’ai voulu et rien d’autre » est immense.
Le problème se manifeste de trois façons :
Fuite de tokens. Les agents n’ont pas de points d’arrêt naturels. Sans garde-fous explicites, ils continuent d’itérer. « Encore un refactor », pense l’agent, et soudain vous avez brûlé votre budget mensuel.
Dérive du périmètre. Une demande d’« améliorer la gestion des erreurs » devient « réécrire tout le système de gestion des erreurs, ajouter l’observabilité, refactoriser la couche de logs, et implémenter le traçage distribué ». L’agent n’avait pas tort — il était exhaustif. Mais ce n’était pas ce que vous aviez demandé.
Latence imprévisible. Vous ne pouvez pas savoir combien de temps prendra une tâche agentique. Cela dépend du nombre de sous-tâches que l’agent décidera de lancer, du nombre d’échecs rencontrés, et s’il décide de réessayer ou de pivoter. Cela rend les workflows pilotés par agents impossibles à planifier dans des systèmes de production.
Ce qu’était (et n’était pas) le consensus du sommet
Il n’y avait pas de consensus sur les solutions. Certaines équipes utilisent des limites de tokens strictes. D’autres implémentent des « points de contrôle d’agent » — forçant les agents à s’arrêter et à demander la permission avant de continuer. Quelques-unes s’orientent vers des systèmes d’agents hiérarchiques où un « agent manager » supervise des agents travailleurs et peut les interrompre.
L’approche de FlowHunt — des définitions explicites de workflow avec des nœuds d’agent, des gestionnaires d’erreurs et une logique de branchement — a été mentionnée plusieurs fois comme un modèle potentiel. L’idée : ne laissez pas les agents décider de la structure du workflow. Définissez-la à l’avance, puis laissez les agents exécuter des étapes individuelles.
Mais même cela ressemblait à un pansement. Le vrai problème est que le comportement des agents est intrinsèquement probabiliste. Vous pouvez réduire la variance, mais pas l’éliminer.
Comment la fracture OpenAI-Anthropic a-t-elle redéfini ce que signifie « du bon code » ?
Lundi matin, Ryan Lopopolo d’OpenAI est monté sur scène et a délivré une keynote qu’on pourrait résumer ainsi : Arrêtez de lire le code. Devenez un milliardaire en tokens.
Son argument : Dans un monde agentique, le volume de code est la métrique qui compte. Votre agent devrait générer des milliers de lignes par jour. Votre rôle est de définir la spec de sortie et de laisser l’agent maximiser le débit. Lire et comprendre chaque ligne est un goulot d’étranglement. Faites confiance aux tests. Faites confiance à l’agent. Allez vite.
Le mercredi, Mario Zechner d’Anthropic a délivré la contre-keynote : Ralentissez et lisez ce foutu code.
Son argument : La vitesse est un piège. Chaque ligne de code que votre agent écrit est une dette. Vous devez la comprendre, raisonner dessus, et être capable de la maintenir. Les équipes qui gagneront dans cinq ans sont celles qui privilégient la clarté et l’intention sur la vélocité. Les agents devraient être des outils pour réfléchir, pas pour générer du code sans réfléchir.
Le spectre
Le sommet s’est globalement divisé en trois camps :
| Position | Défenseurs | Approche | Risque |
|---|---|---|---|
| Maximaliste en tokens | OpenAI, certains ingénieurs de scale-ups | Laisser les agents générer agressivement ; se concentrer sur la qualité de la sortie via les tests | Bases de code inmaintenables, dette de sécurité, fragilité technique |
| Milieu intentionnel | La plupart des ingénieurs d’entreprise | Utiliser les agents pour l’échafaudage ; les humains fournissent l’architecture et le goût | Vitesse plus lente, mais systèmes plus stables |
| Code d’abord | Anthropic, certains ingénieurs de recherche | Les agents augmentent la pensée humaine ; les humains écrivent la plupart du code | Débit inférieur, mais qualité de code maximale |
Aucun camp n’a tort. Le désaccord porte sur à quoi ressemble l’échec. Lopopolo optimise pour la vitesse d’itération. Zechner optimise pour la durabilité. En 2026, les équipes apprennent qu’on ne peut pas optimiser pour les deux.
Le problème de l’entretien
Une conséquence concrète : le recrutement est cassé. Si vous êtes maximaliste en tokens, peu importe qu’un candidat sache coder — ce qui compte c’est qu’il sache prompter efficacement et évaluer la sortie d’un agent. Si vous êtes code-d’abord, vous voulez voir un raisonnement technique profond.
Donc quand un candidat arrive en entretien, ni l’intervieweur ni le candidat ne savent par rapport à quel cadre ils sont évalués. Un participant au sommet le décrivait comme « passer un entretien dans le brouillard ».
Prêt à développer votre entreprise?
Commencez votre essai gratuit aujourd'hui et voyez les résultats en quelques jours.
Pourquoi les IDE meurent-ils alors que le trafic GitHub explose ?
GitHub a rapporté une augmentation de 15x de son trafic d’une année sur l’autre. Cloudflare a rapporté des pics similaires. Pendant ce temps, les IDE traditionnels — VS Code, JetBrains, Sublime — voient leur usage décliner parmi les équipes nativement IA.
Cela semble contradictoire jusqu’à ce que vous compreniez ce qui se passe réellement.
L’IDE était un outil de réflexion local
Un IDE a été conçu pour qu’un seul développeur écrive du code localement. Il avait la coloration syntaxique, l’autocomplétion, des outils de débogage et un arbre de fichiers. C’était un environnement autonome.
Ce modèle s’effondre quand votre « développeur » est un agent. Un agent n’a pas besoin de coloration syntaxique. Il n’a pas besoin d’un débogueur. Il a besoin de :
- Accès simultané à plusieurs fichiers
- La capacité d’exécuter du code et de voir les résultats
- Intégration avec le contrôle de version
- Fonctionnalités de collaboration (car l’agent et l’humain travaillent ensemble)
Tout cela vit désormais dans le navigateur. GitHub Codespaces, VS Code Web et les outils similaires remplacent les IDE locaux.
Ce qui croît réellement
Le pic de trafic de GitHub, ce ne sont pas des développeurs qui écrivent du code dans le navigateur. Ce sont des développeurs qui examinent, commentent et mergent du code généré par des agents. C’est la couche de collaboration qui explose, pas la couche d’édition.
C’est pourquoi Cloudflare voit aussi des pics de trafic — les développeurs utilisent l’infrastructure cloud pour exécuter des agents et orchestrer des workflows. Le modèle « IDE local + environnement de développement local » est remplacé par « orchestration d’agents cloud-native + revue basée sur le navigateur ».
L33T C0d3 est mort
Une session portait précisément ce titre. Le propos : la notion romantique de l’ingénieur brillant, seul à son clavier, ciselant un code élégant — c’est fini. Le code est désormais une sortie collaborative entre l’humain et l’agent. Les compétences qui comptent sont :
- Prompt engineering (comment spécifier ce que vous voulez)
- Évaluation de la sortie (le code de l’agent est-il bon ?)
- Pensée architecturale (dans quelle structure l’agent doit-il travailler ?)
- Intégration (comment le code généré par l’agent s’intègre dans les systèmes existants ?)
Écrire du code élégant n’est plus une compétence primaire. C’est quelque chose que font les agents. Les humains font tout le reste.
Que se passe-t-il vraiment avec le MCP — mort ou en plein essor ?
Ce fut le débat le plus confus du sommet.
D’un côté, les ingénieurs IA individuels et les mainteneurs de frameworks d’agents disaient : « Le MCP est mort. Nous n’en avons pas besoin. Nos agents peuvent simplement appeler les API directement. »
De l’autre, les architectes d’entreprise et les équipes sécurité disaient : « L’adoption du MCP s’accélère plus vite que nous ne pouvons construire des outils pour lui. »
Les deux affirmations sont vraies. Elles décrivent des populations différentes.
Pourquoi les ingénieurs IA pensent que le MCP est mort
Pour un développeur solo construisant un agent simple, le MCP ajoute de la friction. Vous devez :
- Définir des serveurs MCP pour vos outils
- Gérer la surcharge du protocole
- Gérer l’authentification et l’autorisation
- Déployer et maintenir les serveurs
Il est plus facile de donner à votre agent un accès direct à l’API et de le laisser se débrouiller.
Pourquoi les entreprises adoptent rapidement le MCP
Pour une organisation qui fait tourner des agents en production, le MCP devient soudainement essentiel. Voici pourquoi :
Isolation de sécurité. Vous ne voulez pas que les agents aient un accès direct à votre base de données, votre système de paiement ou les données clients. Le MCP vous permet de créer une interface contrôlée que les agents peuvent appeler sans exposer les systèmes sous-jacents.
Auditabilité. Chaque action de l’agent passe par le serveur MCP, qui la journalise. Vous avez un enregistrement complet de ce que l’agent a fait et pourquoi.
Gestion des identifiants. Au lieu d’intégrer les clés API dans les prompts d’agents ou les variables d’environnement, les serveurs MCP gèrent les identifiants en toute sécurité.
Limitation de débit et application des quotas. Vous pouvez contrôler combien d’une ressource un agent peut consommer.
Selon CData Software, 80 % des entreprises du Fortune 500 évaluent ou implémentent le MCP début 2026, principalement pour ces raisons.
La résolution
Le consensus du sommet : le MCP n’est pas mort. Il n’est simplement pas pertinent pour les 80 % du développement IA qui est expérimental et solo. Mais pour les 20 % qui sont production et multi-équipes, le MCP devient incontournable.
C’est pourquoi les MCP Apps prolifèrent. Anthropic, OpenAI et des fournisseurs tiers construisent des serveurs MCP pré-configurés pour les outils courants (Salesforce, Slack, Jira, bases de données). Les entreprises peuvent les adopter sans construire de serveurs personnalisés.
Rejoignez notre newsletter
Recevez gratuitement les derniers conseils, tendances et offres.
L’IA nous rend-elle plus productifs ou juste plus surmenés ?
C’est ici que le sommet s’est assombri.
L’IA était censée être un multiplicateur de force. Vous passeriez moins de temps sur des tâches routinières et plus sur la réflexion stratégique. La productivité exploserait.
Au lieu de cela, la productivité a explosé — et les attentes en matière de charge de travail aussi.
Le paradoxe de Jevons en temps réel
Le paradoxe de Jevons, appliqué à l’origine à la consommation de charbon, dit : Quand une ressource devient plus efficace, la consommation totale augmente, car la ressource devient moins chère et plus attrayante.
En termes d’IA : Les agents ont rendu la génération de code moins chère et plus rapide, donc les managers attendent maintenant de chaque ingénieur :
- Livrer 10x plus de sortie
- Écrire une documentation complète
- Construire des suites de tests complètes
- Prendre en charge l’internationalisation (i18n)
- Gérer les cas limites
- Faire tout cela en solo
Les gains de productivité ont été consommés par des attentes gonflées.
Ce qu’ont dit les ingénieurs
Un ingénieur d’une startup basée à Londres : « J’écrivais 500 lignes de code par jour et je me sentais productif. Maintenant j’écris 5 000 lignes par jour — générées par des agents — et je suis épuisé parce que je dois tout relire, tester, documenter, et l’expliquer aux parties prenantes. Je fais des semaines de 60 heures. »
Un autre : « Mon manager dit : “Tu as un agent maintenant, donc tu devrais pouvoir gérer deux fois plus de projets.” Je ne suis pas plus productif. Je suis juste plus occupé. »
Un chercheur : « Les agents sont bons pour générer du code. Ils ne sont pas bons pour décider quel code générer. Ce fardeau de décision a été entièrement déplacé vers les humains. Nous n’automatisons pas la partie difficile ; nous automatisons la partie facile et forçons les humains à réfléchir plus. »
L’angle mort de la productivité
La California Management Review de UC Berkeley a publié en janvier 2026 une recherche documentant ce phénomène. L’idée clé : Le déploiement de l’IA ne réduit pas le travail ; il change la nature du travail.
Ancien travail : Écrire du code. Nouveau travail : Diriger les agents, évaluer la sortie, maintenir la qualité, gérer la dérive du périmètre.
Le nouveau travail est cognitivement plus dur, même s’il y a moins de frappe.
Pourquoi l’Europe est-elle si hésitante sur l’ingénierie de l’IA ?
Le sommet avait un fort contingent européen, et leur message était cohérent : L’Europe ne va pas aussi vite que les États-Unis dans l’adoption de l’ingénierie en IA.
Le surplomb réglementaire
La loi européenne sur l’IA est encore en cours d’implémentation. Les entreprises sont incertaines sur la responsabilité. Si un agent IA prend une décision qui nuit à un client, qui est responsable ? L’entreprise ? Le fournisseur du modèle ? L’ingénieur ?
Cette incertitude paralyse. De nombreuses entreprises européennes attendent de voir comment se déroulent les premiers procès avant de construire des systèmes agentiques sérieux.
L’écart de compétences
Les ingénieurs logiciels traditionnels en Europe ne deviennent pas des ingénieurs IA au même rythme qu’aux États-Unis. Il y a du scepticisme sur le transfert des compétences. De nombreux ingénieurs européens attendent de voir si l’ingénierie IA est une vraie voie de carrière ou un cycle de hype.
Préoccupations de confidentialité
L’Europe est aussi plus prudente avec la gestion des données. Les agents ont besoin d’accès aux données pour être utiles. Mais les entreprises européennes hésitent à donner aux agents accès aux données clients, même avec les garde-fous MCP en place.
La voie à suivre
Les ingénieurs européens du sommet n’étaient pas anti-IA. Ils étaient pro-prudence. Le sentiment : « Les États-Unis vont vite et cassent des choses. Nous allons moins vite et essayons de ne pas tout casser. Dans cinq ans, nous verrons qui avait raison. »
Comment les rôles d’ingénierie en IA changent-ils vraiment ?
À la fin du sommet, un schéma a émergé : Les rôles traditionnels d’ingénierie logicielle sont vidés et remplacés par trois nouveaux archétypes.
Les trois rôles
| Rôle | Responsabilité | Compétences |
|---|---|---|
| AI PM | Définir le comportement de l’agent, les métriques de succès, les contraintes | Pensée produit, conception de prompts, frameworks d’évaluation |
| Nounou d’agents | Surveiller l’exécution, attraper les erreurs, intervenir si besoin | Débogage, observabilité, gestion des erreurs, réponse aux incidents |
| Arbitre du goût | Évaluer la qualité de la sortie, fournir un retour, guider le raffinement | Revue de code, pensée architecturale, jugement esthétique |
Aucun de ces rôles n’implique d’écrire du code au sens traditionnel. Tous impliquent de diriger, évaluer et raffiner le comportement de l’agent.
Ce qui disparaît
Les rôles « d’ingénieur junior » sont comprimés. Il n’y a plus de chemin clair de « je peux écrire du code simple » à « je peux architecturer des systèmes ». Les étapes intermédiaires sont automatisées.
Cela crée une falaise des compétences : soit vous êtes bon en prompting et en évaluation (auquel cas vous êtes précieux), soit vous ne l’êtes pas (auquel cas vous êtes en concurrence avec les agents).
Ce qui croît
Les rôles qui exigent du goût, du jugement et une pensée architecturale croissent. De même que les rôles qui exigent une expertise profonde du domaine (car les agents ont besoin d’humains pour évaluer s’ils résolvent le bon problème).
Le sommet n’avait pas de consensus pour savoir si c’est bien ou mal. Certains voyaient cela comme une libération du codage routinier. D’autres comme une menace pour la profession.
Qu’est-ce qui a changé entre décembre 2025 et février 2026 ?
Une section du sommet était consacrée à un point d’inflexion spécifique : quelque chose a bougé dans l’écosystème des agents IA autour du nouvel an.
Les logiciels auto-améliorants sont devenus réels
OpenClaw et des frameworks similaires ont commencé à permettre aux agents d’améliorer itérativement leurs propres sorties sans prompting humain constant. Au lieu de « agent, écris une fonction pour calculer X », c’est devenu « agent, écris une fonction pour calculer X et continue de l’améliorer jusqu’à ce qu’elle passe tous les tests et gère les cas limites ».
L’idée clé, articulée par plusieurs chercheurs : Cessez de demander aux agents des conseils triviaux.
Au lieu de demander à un agent de « améliorer cette fonction », demandez-lui de « rendre cette fonction à toute épreuve ». Laissez-le décider ce que cela signifie. L’agent va :
- Écrire des tests
- Trouver les cas limites
- Refactoriser pour la clarté
- Ajouter la gestion d’erreurs
- Documenter la logique
Tout cela sans qu’on le lui demande pour chaque étape.
Cela a changé le modèle mental de « l’agent comme outil » à « l’agent comme contributeur autonome ». Et cela a changé la dynamique de la charge de travail : au lieu que les agents réduisent le travail humain, ils l’augmentent (car les humains doivent désormais évaluer une sortie d’agent beaucoup plus sophistiquée).
Les contradictions avec lesquelles nous vivons
Le sommet s’est terminé sans résolution, ce qui semblait honnête. Voici les contradictions qui définissent l’ingénierie en IA en avril 2026 :
Contradiction 1 : Les agents sont assez puissants pour être dangereux (le FOMAT est réel), mais pas assez puissants pour être laissés sans supervision.
Contradiction 2 : La vitesse et la qualité sont traitées comme des opposés, mais les deux sont nécessaires.
Contradiction 3 : Le MCP est simultanément mort (pour les individus) et florissant (pour les entreprises).
Contradiction 4 : L’IA nous a rendus plus productifs, mais aussi plus surmenés.
Contradiction 5 : Tout le monde construit avec des agents, mais personne n’a trouvé comment bien construire avec eux.
Contradiction 6 : L’ingénierie en IA est une vraie voie de carrière, mais les compétences que nous pensions importantes (écrire du code) ne le sont plus.
Ce ne sont pas des problèmes à résoudre. Ce sont des tensions à gérer. Les équipes qui gagneront en 2026 sont celles qui reconnaissent ces contradictions au lieu de faire comme si elles n’existaient pas.
Foire aux questions
Ce que nous retenons
Le sommet de Londres était un instantané d’une profession en transition. L’ingénierie en IA est réelle, mais ce n’est pas ce que nous pensions. C’est plus chaotique, plus contradictoire, et plus dépendant de l’humain que ne le suggérait le hype.
Les meilleurs ingénieurs du sommet n’étaient pas ceux aux agents les plus sophistiqués. C’étaient ceux qui avaient compris que les agents sont un outil pour penser, pas un remplacement de la pensée. C’étaient ceux qui avaient construit des processus pour gérer le comportement des agents, évaluer la sortie, maintenir la qualité. C’étaient ceux qui avaient accepté que les gains de productivité s’accompagnent de nouvelles formes de travail, pas de moins de travail.
Si vous construisez des systèmes d’IA en 2026, les leçons du sommet sont claires :
L’orchestration compte plus que la capacité de l’agent. Un agent médiocre avec une bonne orchestration bat un agent brillant sans contrôles.
La clarté est plus précieuse que la vitesse. Aller vite et casser des choses marche jusqu’à ce que ça ne marche plus. À l’échelle, ça ne marche pas.
L’adoption en entreprise est réelle, mais l’adoption individuelle reste expérimentale. Si vous êtes un développeur solo, vous pouvez aller vite. Si vous êtes une équipe, il vous faut des garde-fous.
Les compétences qui comptent ont changé. Prompt engineering, évaluation de sortie et pensée architecturale sont les nouvelles compétences centrales.
Attendez-vous à travailler plus dur, pas plus facilement. L’IA est un multiplicateur de productivité, mais les gains sont absorbés par des attentes plus élevées. Planifiez en conséquence.
Le sommet n’a pas répondu à la question « À quoi ressemble l’ingénierie en IA ? ». Il nous a montré la réponse : elle nous ressemble, à essayer de comprendre en temps réel.
{{ cta-dark-panel heading=“Cessez d’orchestrer manuellement vos agents” description=“Le générateur de workflows de FlowHunt vous permet de définir le comportement des agents, de poser des garde-fous et d’automatiser des tâches d’IA multi-étapes. Plus de FOMAT. Plus de supputations sur ce que font vos agents.” ctaPrimaryText=“Essayer FlowHunt gratuitement” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Réserver une démo” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
