2026, l’année où l’IA devient infrastructure : Ce que l’AWS Summit Paris 2026 révèle sur la gouvernance des agents

L'état du marché en quelques repèresL'état du marché en quelques repères

Présence AWS France : chiffres annoncés en ouverture par Amélie Clugnet Veron, Directrice AWS France.

AWS fête ses vingt ans et investit six milliards d'euros en France : data centers, extension des régions, formation. Un millier de collaborateurs, plus de trois cents partenaires, un écosystème qui structure une part significative de l'offre cloud française. Mais les chiffres les plus révélateurs concernent les freins à l'adoption de l'IA, et ils éclairent directement l'enjeu de gouvernance qui traverse tout cet article.

Les trois freins à la transformation IA en France citées par AWS.

41 % des entreprises françaises citent le manque de compétences IA et numériques comme premier frein. Sur chaque cent euro dépensé en informatique, quarante-deux vont à la conformité. Et 32 % additionnels citent l'incertitude réglementaire comme obstacle tandis que 70 % des mêmes entreprises déclarent tirer des gains tangibles de l'IA. Ce dernier différentiel dessine la forme exacte de la demande à venir. Les organisations ne cherchent plus des outils : elles cherchent des cadres méthodologiques sécurisés et conformes qui leur permettent d'industrialiser sans perdre le contrôle. C'est une fenêtre stratégique pour les praticiens de la cybersécurité condition de savoir s'y positionner.

Retenons un chiffre : 42 € de conformité sur chaque 100 € IT. Ce ratio justifie à lui seul toute démarche de compliance-as-code (NIS2, CRA, DORA, EU AI Act) et toute approche qui transforme la conformité en accélérateur plutôt qu'en frein. L'EU AI Act et sa sanction potentielle de 7 % du CA mondial changent définitivement la physique des décisions : on ne repousse plus la gouvernance IA à « phase 2 » d'un programme.

La keynote : souveraineté, productivité agentique et le chiffre des quinze minutes

La keynote de deux heures a été construite autour d'une métaphore portée par Amélie Clugnet Veron : celle de la fusée au décollage. Formation, navigation, structure, souveraineté quatre piliers censés symboliser ce qu'AWS veut apporter à la transformation française. Le dispositif narratif est un peu appuyé, mais la suite de la matinée lui confère une densité réelle. Trois signaux stratégiques méritent l'attention des RSSI.

L'European Sovereign Cloud comme argument d'infrastructure

L'arrivée sur scène de Stéphane Israël, ancien président d'Arianespace désormais chez AWS, est une signalétique politique : AWS veut opérer dans les secteurs régaliens. Ariane 6, cité comme premier client de l'European Sovereign Cloud, achève le tableau. Les mêmes services que le Cloud public pas une offre dégradée mais opérés dans une région indépendante par des entités juridiques européennes, avec garantie d'absence d'interdépendance vis-à-vis des autres régions mondiales, et mécanismes d'audit dédiés.

Pour les RSSI d'organisations régulées, cette proposition lève l'objection historique sur la dépendance juridique US tout en conservant l'accès au catalogue AWSBedrock, AgentCore, deux cent quarante services. Ce n'est évidemment pas la fin de la discussion souveraineté (la question du Cloud Act reste ouverte, les garanties dépendent de la structure juridique effective de l'opérateur local), mais c'est une proposition technique et juridique suffisamment structurée pour mériter un examen sérieux dans les trajectoires d'architecture à trois-cinq ans, en regard des offres 3DS Outscale, OVHcloud ou S3NS.

Le basculement sémantique : du « pourquoi ? » au « pourquoi pas ? »

Stéphane Hadinger, Head of Technology France, a formulé un glissement qui mérite qu'on s'y attarde. Pendant dix ans, la conversation IA dans les entreprises a tourné autour du « pourquoi » : pourquoi ce cas d’usage ? pourquoi ce modèle ? pourquoi maintenant ? En 2026, dit-il, la question devient « pourquoi pas ?» ce qui suppose que la démonstration de valeur est faite, que les outils existent, que la friction est réduite au point où l'absence d'agentique dans un flux métier devient une anomalie à justifier. Pour les RSSI, ce basculement signifie que la pression d'adoption va s'intensifier massivement côté métier, et que la posture de « gardien qui dit non » deviendra de plus en plus difficile à tenir. La seule posture tenable est celle du partenaire qui propose des cadres de déploiement sécurisés pas des interdictions.

Le chiffre des quinze minutes et ses implications

Le chiffre le plus marquant de la matinée : un développeur senior ne consacre en moyenne que quinze minutes par jour à écrire du code. Le reste : spécification, architecture, test, debug absorbe l'essentiel. C'est un cadrage qui donne sens à toute la stratégie agentique d'AWS : les agents ne cherchent pas à remplacer le développeur mais à industrialiser les quatre blocs chronophages. Kiro, positionné comme concurrent de Claude Code et Cursor, incarne cette vision.

Un retex interne AWS illustre le propos. La refonte d'Amazon Bedrock initialement trente personnes sur dix-huit mois a été rejouée avec l'outillage agentic en six personnes sur six mois : seize fois moins cher, trois fois plus rapide. Le ratio appelle à la prudence effets de périmètre, de dette technique préalablement absorbée, d'apprentissage mais il fournit un point de repère que les directions techniques vont citer dans leurs business cases, et que les RSSI vont devoir savoir discuter.

Bureau Veritas et l'émergence de l'audit IA structuré

Radar Bureau Veritas : huit dimensions d'évaluation (explicabilité, équité, gouvernance, confidentialité & sécurité, robustesse, sûreté, transparence, contrôlabilité).

Marc Roussel, EVP chez Bureau Veritas, a livré l'intervention la plus utile pour qui s'intéresse aux intersections IA / conformité / audit. 68 % des entreprises ont du mal à interpréter l'EU AI Act 113 articles, rôles multiples, matrice de risques complexe. L'offre Bureau Veritas combine pré-audit documentaire, tests prédictifs et audit terrain. Le radar à huit axes recoupe largement l'ISO/IEC 42001 et les dimensions AI TRiSM de Gartner.

Pour les praticiens de la cybersécurité, le signal est double. D'un côté, les méthodologies d'audit classiques parfaitement maîtrisées pour les systèmes d'information traditionnels sont structurellement inadaptées à l'audit des systèmes IA, comme l'a reconnu Bureau Veritas lui-même. De l'autre, les nouvelles grilles d'évaluation qui émergent (Bureau Veritas, mais aussi le AI Risk Management Framework du NIST, l'ISO/IEC 42001, le cadre AI TRiSM) convergent vers un jeu de dimensions partagées. C'est une fenêtre pour les RSSI et responsables audit : celui qui formalise la méthodologie d'évaluation IA dans son organisation avant que la réglementation ne l'impose aura un avantage structurel durable.

AgentCore : les six frontières invisibles que l'industrialisation rend visibles

La session Bonnes pratiques avancées pour déployer des agents avec AgentCore, animée par des Solutions Architect AWS avec un retex industriel du Groupe La Centrale, a été la session la plus dense de la journée pour un profil sécurité. Elle mérite un développement approfondi parce qu'elle structure le modèle opérationnel qu'AWS recommande pour industrialiser les agents en entreprise et que chaque brique de ce modèle matérialise une frontière que nous gérions jusqu'ici de façon implicite.

L'architecture de référence : Runtime et Gateway

Cas d'usage « Assistant analyse financière » : un Finance Agent orchestre un Prediction Agent et appelle quatre outils métier via AgentCore Runtime.

Le cas d'usage présenté en ouverture un assistant d'analyse financière fonctionne comme une maquette pédagogique. Un Finance Agent orchestrateur, un Prediction Agent spécialisé, quatre outils métier (calculate_profit_margin, get_exchange_rate, get_revenue_report, get_department_budget), deux types de services distants externes et internes traités différemment en matière d'identité et de réseau. Trois patterns se dégagent.

D'abord, la séparation claire entre agent orchestrateur et agents spécialisés. Un agent ne doit pas être un couteau suisse, il a une responsabilité bien définie et sait déléguer. Ce pattern répète au niveau IA ce que les microservices ont fait au niveau applicatif. Ensuite, l'isolation différenciée des appels externes. Services internes et externes n'ont pas le même profil de risque, ne s'authentifient pas de la même façon, ne transitent pas par les mêmes contrôles réseau. AgentCore rend cette distinction explicite, là où les architectures artisanales la confondent. Enfin, l'exposition uniforme côté application : peu importe la complexité interne, le consommateur voit un runtime unique.

AgentCore Gateway : point d'entrée /mcp unifié qui route vers trois types de cibles (MCP Servers, APIs REST, fonctions Lambda).

La Gateway est la brique la plus importante à comprendre pour un RSSI. Elle expose un endpoint /mcp unique qui permet à tout agent client MCP de lister, invoquer et rechercher des outils. Derrière, elle route vers trois types de cibles : serveurs MCP existants, APIs REST, ou fonctions Lambda. Le cache intégré évite les appels downstream inutiles critique pour maîtriser coût et latence. Mais surtout, la Gateway crée un point d'étranglement gouvernable : tout le trafic agent-outil passe par un endroit unique, visible, filtrable, auditable. C'est le pattern que toute équipe sécurité devrait exiger avant tout déploiement agentic à l'échelle.

La sécurité agentique : trois plans d'identité à gouverner

La sécurité agentique se joue à trois niveaux, chacun à gouverner explicitement. Et c'est ici que le fil rouge de cet article s'incarne le plus fortement : dans les architectures artisanales d'hier, ces trois relations étaient souvent confondues typiquement, l'agent héritait des droits de l'utilisateur invocateur, ce qui est un anti-pattern majeur.

Ce triptyque impose des disciplines opérationnelles nouvelles. Il faut inventorier les agents comme on inventorie les utilisateurs et les comptes de service. Gérer leur cycle de vie : création, promotion, rotation des credentials, révocation. Les attacher à un propriétaire clairement désigné, parce qu'un agent sans propriétaire est une bombe à retardement. Tout cela correspond à des pratiques que les équipes IAM connaissent pour les identités humaines et machines ; il s'agit de les étendre à une troisième population. Les organisations qui ne le font pas dès maintenant accumulent une dette de sécurité invisible qui ne se révélera qu'au premier incident et l'incident sera difficile à investiguer, faute de traçabilité des identités agents.

Observabilité et évaluation : la deuxième ligne de défense

AgentCore Evaluations (preview) : un LLM-juge analyse les traces produites par AgentCore Observability.

AgentCore Observability fournit une trace de bout en bout : coût en tokens, latence par outil, chaînes d'invocation. La bonne pratique rappelée avec insistance : inclure l'observabilité dès le départ, pas la bolter-on après coup. On connaît la chanson l’observabilité ajoutée a posteriori est toujours incomplète et toujours plus coûteuse que l'observabilité native.

AgentCore Evaluations, encore en preview, va plus loin. Un LLM-juge analyse les traces, produit des résultats et des explications, et alimente des tableaux de bord d'évaluation continus. C'est l'équivalent d'un SonarQube pour agents avec la promesse de détecter en continu les dérives de comportement, les régressions de qualité, les interactions anormales avec les outils. Le pattern est celui du LLM-as-a-judge, appliqué à l'évaluation d'agents en production plutôt qu'à l'évaluation de datasets d'entraînement. Il y a là une discipline de quality engineering entièrement à construire.

Le retex Euronext : quand la gouvernance MCP devient une discipline opérationnelle

La session Secure MCP Platform for Generative AI with Bedrock AgentCore Gateway, co-animée par Ruben Silva, Cloud Engineer chez Euronext, et des architectes AWS, a été la séquence la plus mature de la journée côté sécurité. Elle répond à une question très concrète : comment passer de cinquante outils MCP artisanaux à plusieurs milliers en production, sans exploser la dette de sécurité ?

Le point de rupture et pourquoi il arrive plus vite qu'on ne le pense

Le cas initial d'Euronext un customer support IA avec quelques utilisateurs internes fonctionnait bien. Puis la réalité industrielle a frappé : des milliers d'utilisateurs, des dépendances multiples, des intégrations MCP hétérogènes, des équipes agents distinctes qui déployaient chacune leurs propres serveurs MCP sans coordination. L'architecture ne passe plus. Les auteurs font un parallèle explicite avec le passage du monolithe aux microservices : on refait le même trajet, mais avec les agents et leurs outils. Quatre problèmes apparaissent simultanément : la nécessité d'un point unique de communication, le besoin d'un contrôle d'accès fin et contextualisé, l'exigence d'une observabilité transverse, et la gouvernance du cycle de vie des outils MCP versioning, dépréciation, rollback.

L'architecture cible : enterprise-grade MCP

Architecture Euronext : développeur (VS Code + GitHub Copilot, SSO Azure Entra ID) → AgentCore Gateway (SSO + AD Group Auth, PII Guardrails, Private ALB + VPC, Tool Routing) → MCP Servers intégrés (GitLab, Atlassian, Coralogix ; Figma en attente).

L'architecture tient sur une ligne, mais elle concentre une quantité impressionnante de décisions. Le développeur n'adresse qu'un endpoint/mcp authentifié via SSO Azure Entra ID avec appartenance à des groupes AD. La Gateway enchaîne quatre fonctions : vérification SSO et groupes AD, PII Guardrails qui filtrent les données sensibles en entrée comme en sortie, mise en VPC privé via ALB, et tool routing vers les cibles. Figma reste en attentele support 3-legged OAuth n'est pas encore disponible dans le prototype ce qui témoigne d'une honnêteté technique appréciable.

Connectivité privée : le VPC client atteint l'AgentCore Gateway data plane via AWS PrivateLink, sans exposition Internet.

La topologie réseau est irréprochable pour un contexte financier régulé : AWS PrivateLink entre le VPC client et le Gateway endpoint opéré par AWS. Pas de sortie Internet, pas de NAT Gateway côté sensible. Ce pattern est exactement celui à recommander à tout contexte régulé : banque, défense, santé, énergie et il répond préventivement à trois objections classiques : nos données transitent-elles en dehors de notre périmètre ? à qui appartient le plan de ccontrôle ? et comment isoler ce trafic de nos autres workloads ?

Fine-grained access control : exemple qui change la discussion

Fine-grained access control : un même Pricing Agent obtient des décisions d'accès différentes selon qu'il est invoqué par un client externe ou un administrateur interne.

Ce schéma vaut plus que tous les discours sur la gouvernance MCP. Un même Pricing Agent est invoqué dans deux contextes. Côté client externe, AddPromotions est refusé (Deny) tandis que SearchPromotions reste autorisé. Côté administrateur interne, les deux opérations sont ouvertes. Mêmes outils MCP, même agent, décisions d'accès radicalement différentes tout se joue dans le contexte d'appel et dans la policy. Ce pattern disqualifie toute une génération d'approches simplistes où l'agent hérite d'un rôle unique attribué au démarrage. Il faut combiner qui appelle et dans quel contexte, et l'exprimer dans un langage de policy suffisamment expressif.

L'électrification du SDLC : du GitLab DAP à la méthodologie AI-DLC

Les deux dernières sessions techniques se lisent ensemble : la session sponsorisée GitLab sur Duo Agent Platform et la session de clôture sur l'AI-Driven Development Lifecycle. La première propose une réalisation concrète : une plateforme IA multi-agents intégrée au cycle DevSecOps. La seconde propose le cadre méthodologique qui donne sens à ces réalisations. L'outil sans méthode produit du chaos ; la méthode sans outil reste théorique.

Le paradoxe GitLab : faster code ≠ faster delivery

L'enquête McKinsey State of AI 2026 indique que l'usage de l'IA dans les équipes de développement a doublé sur les deux dernières années. Pourtant, l'approche est plus fragmentée que jamais chaque développeur choisit son outil, chaque équipe ses conventions et la chaîne livrée ne s'accélère pas autant que prévu. D'où le paradoxe : « faster code does not equal faster delivery ». La leçon structurelle rejoint notre fil rouge : tant que l'usage de l'IA reste individuel et non gouverné, les gains de productivité s'évaporent dans l'intégration, le debug en aval, la dette d'inconsistance. Pour un RSSI, ce paradoxe a un corollaire direct : une IA de développement non gouvernée ne crée pas seulement de la dette technique, elle crée de la dette de sécurité du code généré sans revue, sans convention, sans respect des référentiels de secure coding.

GitLab Duo Agent Platform propose une réponse : une orchestration multi-agents alignée sur le cycle DevSecOps complet (plan, code, build, test, secure, deploy, operate), alimentée par Amazon Bedrock derrière une AI Gateway auto-hébergée. Cette topologie apporte un contrôle fin des modèles utilisés par étape, la résidence des données (aucun prompt ni code ne sort vers des services non maîtrisés), la conformité par design (journalisation centralisée, audit trail), et la scalabilité via les services managés AWS. Pour les organisations régulées, ce pattern « GitLab self-managed + Bedrock via AI Gateway privée » répond frontalement à l'objection récurrente : « on ne peut pas envoyer notre code en clair chez un fournisseur IA ». La réponse technique est désormais standardisée et reproductible.

AI-DLC : l'analogie de l'électrification

Le SDLC traditionnel : « tout le monde attend tout le monde ». Chaque « STOP » matérialise un goulot d'étranglement entre les silos.

L'analogie proposée pour penser la sortie de ce schéma est celle de l'électrification des manufactures. Dans les ateliers pré-électriques, toutes les machines étaient reliées à un arbre de transmission central entraîné par une machine à vapeur unique. Panne sur l'arbre, arrêt de tout l'atelier. L'électrification a donné à chaque machine son propre moteur libérant des gains d'un ordre de grandeur, changeant la topologie des usines, transformant la nature du travail. L'IA dans le SDLC, c'est le même basculement : chaque étape peut fonctionner à son propre rythme, pilotée par un agent spécialisé. Mais et c'est le point que les sessions de sécurité ont martelé : un moteur individuel non gouverné est plus dangereux qu'un arbre de transmission centralisé. D'où la nécessité d'un cadre méthodologique.

AI-DLC positionné entre le vibe coding (autonomie maximale) et le développement IA-assisté classique (contrôle maximal).

L'AI-DLC se positionne comme point d'équilibre entre deux extrêmes. Le vibe coding, autonomie maximale de l'agent, risqué en production. Le développement assisté classique, contrôle total de l'humain, peu de gains. L'AI-DLC cherche un troisième point : l'IA orchestre (planification, décomposition, propositions d'architecture, génération), les ingénieurs arbitrent (validation, décisions structurantes, supervision). Ce n'est pas un compromis mou : c'est une répartition précise des responsabilités fondée sur les forces relatives de chacun.

AI-Driven Development Lifecycle : Inception → Construction → Opérations. Chaque étape enrichit le contexte pour la suivante.

Trois phases structurent l'AI-DLC. L'Inception regroupe l'établissement du contexte (standards, code existant, dépendances, contraintes réglementaires), l'élaboration de l'intention via des user stories, et la planification en unités de travail. C'est ici que se joue le shift-left compliance : les exigences EU AI Act, NIS2, CRA, DORA sont injectées dès le cadrage, pas découvertes à l'audit final. La Construction distribue la génération de code, de tests, l'ajout des composants d'architecture (secrets, observabilité, sécurité), le déploiement IaC. Les Opérations couvrent le déploiement production et la gestion des incidents assistée par un agent DevOps qui effectue root cause analysis, mesure d'impact et proposition de remédiation l’humain gardant le pouvoir de décision.

La méthodologie AI-DLC déclinée en neuf disciplines, toutes IA-assistées, réparties sur les trois phases.

Le retex Amazon Payments complète le tableau : quatre cents projets d'expérimentation ont été menés avant l'industrialisation via l'AI-DLC. Cinq principes opérationnels ont émergé. Commencer par intégrer l'IA dans le flux existant avant de le transformer. Donner à l'IA l'accès au code, à la documentation et aux outils, pas seulement à un prompt isolé. Utiliser des fichiers de cadrage pour aligner les résultats avec l'intention. Gérer finement le contexte, parce que c'est le contexte et non le modèle qui détermine la qualité de la sortie. Et favoriser l'innovation de manière responsable, avec garde-fous explicites et human-in-the-loop sur les décisions impactantes.

Cybersécurité française : la résilience collective face à l'explosion des surfaces

La table ronde réunissant Éric Bothorel, député ; Laurent Verdier, Directeur sensibilisation de Cybermalveillance.gouv.fr ; et les responsables sécurité d'AWS France a apporté les chiffres les plus frappants de la journée. Elle articule un propos qui prolonge directement le fil rouge : quand la menace devient contextuelle et industrialisée par l'IA, la défense ne peut plus reposer sur la proximité humaine seule. Elle doit devenir, elle aussi, explicite et réplicable.

L'explosion quantitative et ce qu'elle cache

Le basculement 2024-2025 est spectaculaire. Les demandes d'assistance traitées par Cybermalveillance.gouv.fr passent de 220 000 à 500 000 soit un facteur 2,3 en un an. La part professionnelle baisse en proportion (de 68 % à 6 %), non parce que les entreprises sont épargnées, mais parce que la menace grand public explose à un rythme sans précédent, et que les attaquants disposent d'une surabondance de données personnelles pour contextualiser leurs scénarios. Cette contextualisation est le point de bascule : une IA d'attaquant nourrie de données personnelles produit des scénarios crédibles, ciblés, difficiles à détecter par les filtres traditionnels.

Typologie 2025 : le phishing détrôné

La surprise de l'année : le phishing n'est plus la menace numéro un. Il est détrôné par le piratage de compte en ligne TPE, PME, associations, mot de passe simple ou recyclé. Puis le social engineering contextualisé, la fraude aux virements (BEC), et la violation de données qui fait des entreprises des cibles premières en tant qu'hébergeurs de données collaborateurs, clients et partenaires.

Laurent Verdier a insisté : les données fuitées deviennent les munitions des attaques futures. Effet de cumul temporel plus le temps passe, plus le stock de données exploitables croît, plus les attaques deviennent précises. Éric Bothorel prolonge : « Plus les attaquants disposent de données, plus l'IA est efficace. Donc la consommation de la donnée explose aussi. » Conséquence directe pour les architectures : le principe de minimisation des données n'est plus seulement une exigence RGPD, c'est une exigence de sécurité opérationnelle. Chaque donnée stockée est une munition potentielle.

Les leviers évoqués convergent : collaboration entre acteurs privés et secteur public (un retex de perquisition conjointe AWS-Microsoft avec le gouvernement indien pour démanteler un réseau de scam), le label Expert Cyber AFNOR, l'évolution législative européenne (NIS2 comme socle, complétée par CRA, DORA, AI Act), et surtout le constat d'hybridation des menaces : espionnage, ingérence, attaque numérique convergent, imposant des défenses distribuées et réplicables. Éric Bothorel l'a formulé sans ambiguïté : face à une menace hybride et distribuée, seule une défense elle-même distribuée et répliquée tient la distance.

Ce que tout cela change pour un praticien de la cybersécurité

Il est temps de ramener l'ensemble à notre terrain de jeu. Le Summit 2026 envoie cinq signaux structurants qui appellent chacun une réponse opérationnelle des RSSI, des architectes sécurité et des consultants experts.

Premier signal : l'identité agent est le nouveau périmètre IAM

AgentCore Identity, le triptyque employé / agent / ressource, le retex Euronext : tout converge vers le même constat. Les identités agents constituent une troisième population IAM qui s'ajoute aux identités humaines et aux identités machines. Elle exige ses propres outils de gestion, ses propres politiques de rotation, ses propres mécanismes d'audit. Les organisations qui ne l'intègrent pas dans leur stratégie IAM dès maintenant accumulent une dette invisible dont le coût de remédiation croît exponentiellement avec le nombre d'agents déployés.

Deuxième signal : la gouvernance MCP est la prochaine gouvernance API

Le protocole MCP (Model Context Protocol) est en train de devenir pour les agents ce que REST est pour les applications. Et comme REST en son temps, il va d'abord proliférer de façon sauvage avant que les organisations ne réalisent qu'il faut le gouverner. Le retex Euronext montre exactement le point de rupture et les solutions architecturales (gateway unique, PII guardrails, tool routing, VPC privé). Les organisations qui mettent en place cette gouvernance dès les premiers outils MCP s'épargnent un retrofit coûteux ; les autres subiront la même courbe d'apprentissage que celle des API non gouvernées des années 2015-2018.

Troisième signal : l'AI-DLC est le cadre de shift-left compliance qui manquait

Quarante-deux euros de conformité sur chaque cent euros IT. Ce chiffre traduit un dysfonctionnement structurel : la conformité arrive trop tard dans le cycle, coûte trop cher, et crée trop de friction. L'AI-DLC, avec sa phase Inception qui cadre le contexte, les standards et les exigences réglementaires avant la première ligne de code, offre un cadre concret pour résoudre ce problème. Ce n'est plus du shift-left compliance déclaratif, c'est un shift-left opérationnel, instrumenté par des agents qui vérifient la conformité en continu.

Quatrième signal : la supply chain s'étend aux modèles, agents et contextes

Les disciplines SBOM, SCA, signature (Sigstore), attestation (SLSA), secure coding toutes acquises à grand effort sur la dernière décennie trouvent une deuxième vie en étant étendues au monde IA. Il faut inventorier les modèles utilisés comme on inventorie les bibliothèques open source. Tracer la provenance des datasets comme on trace la provenance du code. Signer les chaînes d'agents comme on signe les artefacts de build. Attester la conformité des prompts et des contextes comme on atteste celle des configurations d'infrastructure. Le radar Bureau Veritas à huit axes (explicabilité, équité, gouvernance, confidentialité, robustesse, sûreté, transparence, contrôlabilité) offre une grille de référence pour structurer cette extension.

Cinquième signal : la résilience exige des défenses explicites et réplicables

Les chiffres Cybermalveillance (220K → 500K demandes, contextualisation IA des attaques, hybridation des menaces) rappellent une vérité architecturale fondamentale : une défense qui repose sur la proximité humaine, l'expertise tacite et les processus non formalisés ne résiste pas au passage à l'échelle de la menace. La défense doit être explicite documentée, vérifiable, auditable et réplicable automatisable, versionnable, déployable de façon homogène à travers l'organisation. Ce principe, que DevSecOps porte depuis ses origines, n'a jamais été aussi pertinent qu'à l'ère de la menace agentique.

De la gouvernance du code à la gouvernance du contexte

L'AWS Summit Paris 2026 n'est pas un Summit comme les autres. C'est celui où, après deux ans de promesses et de POCs, l'écosystème acte le basculement vers l'industrialisation agentique. Au moment de refermer cette analyse, trois convictions se renforcent et une ouverture plus longue se dessine.

Trois convictions

La gouvernance est redevenue le sujet structurant. Après la course aux POCs, les organisations matures investissent dans ce que j'appelle la plomberie de contrôle : identité, policy, observabilité, évaluation. C'est exactement le terrain de jeu des praticiens DevSecOps, à condition de remonter d'un cran de la gouvernance du code à la gouvernance de la chaîne d'agents. Les compétences supply chain applicative se transposent naturellement ; l'inverse n'est pas vrai.

L'AI-DLC n'est pas un buzzword. C'est une méthodologie cohérente qui absorbe la conformité réglementaire dans sa phase Inception et qui ré-ouvre l'offre de conseil en cadrage de mission. Le premier qui la formalisera en référentiel opérationnel dans l'écosystème français aura un avantage d'image durable.

Le différentiel se joue sur la capacité à rassurer, pas sur les outils. Quarante-deux euros de conformité sur chaque cent euros IT. Sept pour cent du CA mondial en sanction AI Act. Cinq cent mille demandes d'assistance Cybermalveillance en 2025. Ce sont les organisations qui portent le stress et c'est ce stress qu'il faut absorber, structurer et transformer en trajectoire maîtrisée. Nous ne vendons pas de la technologie. Nous vendons de la sérénité face à une complexité qui augmente plus vite que les équipes n'arrivent à l'absorber.

La prochaine bataille sera celle du contexte

Si ce Summit acte le basculement vers l'industrialisation agentique, il laisse entrevoir la bataille d'après. Une phrase, énoncée de biais par les équipes d'Amazon Payments et reprise par La Centrale, mérite d'être méditée : « le prompt engineering ne suffit plus, il faut aller vers le context engineering ». Sous son apparence modeste, elle annonce un déplacement stratégique d'une ampleur comparable à celui qu'on vit actuellement.

L'ère du prompt engineering 2023 à 2025 a été celle où l'on cherchait la formulation magique, le prompt parfait qui débloquerait les capacités du modèle. Métier de bricoleur raffiné. L'ère qui s'ouvre est autre : ce qui compte désormais, c'est l'architecture du contexte dans lequel l'agent opère. Quels outils a-t-il ? Avec quels droits ? Sur quelles données ? Avec quelle mémoire ? Quelle documentation ? Quels standards ? Quels exemples ? Dans quelle chaîne d'agents s'inscrit-il ? Autant de questions qui ne se traitent plus au niveau du prompt, mais au niveau de la plateforme, de la gouvernance et de l'architecture applicative.

Ce déplacement entraîne une conséquence profonde sur notre métier. Le praticien de la cybersécurité de 2028-2030 ne gouvernera plus simplement la chaîne de production logicielle. Il gouvernera la production de contextes les référentiels de code visibles par les agents, les outils MCP disponibles, les documents de cadrage, les mémoires partagées, les règles d'évaluation. La discipline émergente qu'on commence à appeler context engineering regroupera tout cela. Elle empruntera à l'information architecture, au knowledge management, à la sécurité des données, à l'IAM, à l'observabilité, à la gouvernance documentaire. C'est une discipline composite qui n'a pas encore son nom définitif et qui n'a pas encore ses praticiens reconnus.

Trois questions concrètes permettent de s'en saisir dès maintenant. Qui contrôle le contexte dans votre organisation ? Si la réponse est « personne » ou « chacun fait sa cuisine », le risque est massif dérive des agents, incohérence des décisions, fuite de données sensibles injectées comme contexte par négligence. Comment versionnez-vous le contexte ? S'il pilote les décisions des agents, il a les mêmes exigences qu'un code source : versionné, revu, testé, déployé de façon contrôlée. Comment évaluez-vous la qualité d'un contexte ? Un mauvais contexte produit de mauvais agents, aussi sophistiqué soit le modèle sous-jacent.

Je referme cet article sur une conviction. Notre métier n'a jamais été aussi passionnant. Nous ne sommes pas des observateurs de la révolution agentique nous en sommes les opérateurs. Ce que nous construisons ces prochains mois structurera la manière dont les organisations opéreront leur intelligence artificielle pour la décennie qui vient. C'est une responsabilité, c'est une opportunité, et c'est surtout un moment rare où notre discipline se retrouve exactement au centre de l'équation.

Annexe : Glossaire des annonces et concepts clés

Lionel GAIROARD
Expert DevSecOps