La maturité opérationnelle des systèmes d’IA en entreprise progresse plus vite que la capacité des équipes sécurité à les encadrer. Le décalage entre gouvernance et détection des incidents, documenté par le AI Cyber Benchmark 2026 de Wavestone, résume à lui seul la tension qui traverse l’informatique professionnelle cette année : nous déployons plus vite que nous ne protégeons.
Sécurité opérationnelle de l’IA : le point aveugle des entreprises
Le constat du AI Cyber Benchmark 2026 de Wavestone, publié le 25 septembre 2026 auprès de 30 grandes organisations, est net : les politiques de gouvernance et de protection de l’IA progressent, mais la détection, la réponse aux incidents et la reprise après compromission restent en retrait. Le même rapport note que la moitié des organisations interrogées développent désormais leurs propres systèmes d’IA, contre 35 % en 2025.
Ce déséquilibre a des conséquences directes sur les architectures de supervision. Un SOC (Security Operations Center) conçu pour surveiller des flux réseau classiques ne capte pas les comportements anormaux d’un modèle de langage interne qui exfiltre des données d’entraînement. Nous observons que les équipes qui déploient des modèles propriétaires sans adapter leur chaîne de détection s’exposent à des angles morts durables.
Pour suivre l’évolution de ces sujets, les informations informatiques sur Digiterio couvrent régulièrement les enjeux croisés entre cybersécurité et systèmes d’information en entreprise.
Cyber Resilience Act et AI Act : deux réglementations qui changent la donne en 2026
Depuis le 11 septembre 2026, le Cyber Resilience Act impose aux fabricants de produits comportant des éléments numériques vendus dans l’Union européenne de signaler les vulnérabilités activement exploitées et les incidents graves. L’alerte précoce doit être transmise sous 24 heures, suivie d’une notification complète sous 72 heures. Les principales obligations de conformité du règlement s’appliqueront à partir du 11 décembre 2027.
En parallèle, l’AI Act entre dans sa phase de transparence depuis le 2 août 2026. Les fournisseurs et déployeurs de systèmes d’IA sont désormais soumis à des exigences de transparence, notamment pour certains contenus générés.
Pour les DSI, ces deux textes créent un double calendrier réglementaire qu’il faut intégrer dès maintenant dans la roadmap produit.
- Le Cyber Resilience Act touche tout produit connecté mis sur le marché européen, du capteur IoT industriel au logiciel SaaS embarquant un firmware updatable.
- L’AI Act cible spécifiquement les systèmes à haut risque et les contenus générés, avec des obligations de documentation et d’information de l’utilisateur final.
- Les deux textes partagent une logique de notification rapide qui nécessite des processus d’escalade internes bien rodés, absents dans la majorité des entreprises de taille intermédiaire.
Nous recommandons de cartographier dès à présent les produits et systèmes d’IA concernés, puis de vérifier si la chaîne de remontée d’incidents existante respecte les délais imposés. Un audit croisé Cyber Resilience Act et AI Act évite les doublons de conformité et réduit la charge sur les équipes juridiques et techniques.
Développement sur plateformes AI-native : ce que cela implique pour les équipes
Les plateformes de développement AI-native ne se contentent pas d’ajouter une couche d’assistance au code. Elles restructurent le pipeline de livraison logicielle en intégrant la génération, la revue et le test dans une boucle pilotée par un modèle. Le gain de productivité est réel, mais il déplace le risque vers la qualité du prompt engineering et la fiabilité des jeux de tests générés.
Un développeur qui accepte sans vérification le code proposé par un assistant AI-native introduit des dépendances implicites. Nous observons que les régressions silencieuses augmentent quand la revue humaine recule au profit de la vitesse de livraison. Le réflexe à ancrer : chaque suggestion générée passe par le même processus de revue qu’un commit humain.
L’autre point de vigilance concerne la propriété intellectuelle. Les modèles entraînés sur des corpus ouverts peuvent reproduire des fragments de code sous licence restrictive. Les équipes juridiques doivent être associées au choix de la plateforme, pas seulement les architectes logiciels.
Souveraineté numérique et cloud : les arbitrages concrets pour les DSI
La question du cloud souverain dépasse le discours politique. Pour une entreprise qui traite des données de santé, des données judiciaires ou des données classifiées, le choix du fournisseur cloud engage la conformité réglementaire sur plusieurs années. Les offres de cloud souverain européen se multiplient, mais toutes ne présentent pas le même niveau d’isolation vis-à-vis des législations extraterritoriales.
Les critères d’évaluation à prioriser ne sont pas ceux que les commerciaux mettent en avant.
- Localisation physique des données et des clés de chiffrement : vérifier que le fournisseur ne stocke pas les clés dans une juridiction tierce.
- Nationalité de l’entité juridique opérant le service : une filiale européenne d’un groupe américain reste potentiellement soumise au Cloud Act.
- Portabilité réelle des workloads : tester la migration sortante avant de signer, pas après.
- Transparence sur les sous-traitants techniques et leurs propres obligations juridictionnelles.
Nous recommandons de formaliser ces critères dans un cahier des charges cloud dédié, distinct du cahier des charges fonctionnel. La souveraineté se vérifie dans les clauses contractuelles, pas dans les slides commerciales.
Le rythme réglementaire européen ne ralentira pas. Entre le Cyber Resilience Act, l’AI Act et les discussions autour du schéma de certification cloud (EUCS), les DSI qui reportent leur mise en conformité accumulent une dette technique et juridique. Le plus efficace reste de traiter ces obligations comme des contraintes d’architecture dès la phase de conception, plutôt que comme des audits à passer en fin de projet.
