BreizhCamp 2026 : IA, sécurité et souveraineté

Dans cet article, découvrez le focus d’Alexandre sur 3 thématiques du moment.

L’intelligence artificielle évolue à une vitesse sans précédent, élargissant sans cesse le spectre des connaissances à maîtriser et le niveau d’expertise attendu. Autrefois cantonnée à quelques domaines spécialisés, l’IA repousse aujourd’hui les frontières et s’impose dans des secteurs que l’on pensait jusqu’alors incompatibles avec son utilisation.

Dans sa keynote du jeudi matin, Bertrand Rondepierre a parfaitement présenté cette évolution lors de la description de son parcours professionnel. Après un passage chez Google pour développer différentes typologies d’intelligences artificielles (réseau de neurones, apprentissage par renforcement, transformers…), c’est désormais à la tête d’une division du Ministère des Armées qu’il coordonne l’utilisation de l’IA. Face à des enjeux majeurs de confidentialité, le secteur de la défense doit capitaliser sur ces technologies tout en garantissant la souveraineté des données.

L’IA redéfinit les enjeux de sécurité

La DSI de SIPA/Ouest France a présenté un retour d’expérience complet sur l’exploration, l’adoption et l’encadrement de l’IA générative pour ses différentes équipes projet.

Au départ, l’adoption était anarchique : développeurs et collaborateurs expérimentaient librement des outils comme ChatGPT, sans cadre ni vigilance sur les données sensibles. Des signaux faibles (fuites potentielles, code généré non revu, risques RGPD…) ont conduit à une prise de conscience : l’usage de l’IA doit être encadré. Une stratégie a alors été conçue, fondée sur trois piliers : gouvernance, sécurité et mesure.

Le changement de stratégie reflète la maturité acquise par l’organisation. En quelques mois, elle est passée de la mise à disposition de licences dans un pool limité, à une une politique de tarification basée sur la consommation en tokens utilisés. Par défaut une limite basse est appliquée sans justification préalable. La courbe d’adoption s’est stabilisée grâce à une formation ciblée et un accompagnement des utilisateurs.

En cas de dépassement de la limite de tokens mensuelle, une revue des usages de l’IA est effectuée avec des spécialistes :

• rédaction des prompts,
• questionnement de l’usage,
• intégration des outils dès que ceux-ci sont pertinents (MCP, skills, indexing)
• ou encore choix du modèle de LLM.

Les gains sont mesurables :

• augmentation de la fréquence de livraison,
• amélioration de la qualité du code,
• réduction des erreurs récurrentes.

Sécuriser le code mais aussi la chaîne qui le délivre

Les LLM deviennent de plus en plus performants dans l’identification des failles de sécurité. Les modèles Fable et Mythos en sont une illustration : leurs performances sur des benchmarks exigeants, notamment SWE-Bench Pro, témoignent de leur capacité à analyser des systèmes complexes et à détecter des vulnérabilités. Ces capacités expliquent notamment les restrictions imposées par l’administration américaine à leur utilisation hors du cadre étatique.

Utilisés pour analyser les configurations des pipelines CI/CD, ils peuvent permettre d’identifier des vulnérabilités et de générer des payloads d’exploitation automatisés. Face à cette automatisation croissante des capacités offensives, la sécurisation des pipelines CI/CD n’est plus une option, mais un enjeu stratégique.

Par ailleurs, les attaques de supply chain ne cessent de s’intensifier. Le 19 mars 2026, Trivy (un outil de scan de vulnérabilités) a été compromis, entraînant la publication de dizaines d’artefacts malveillants (image Docker, tag Github Action). Des centaines d’organisations ont été touchées, notamment parce que Trivy était intégré à des workflows automatisés sans vérification de l’intégrité des artefacts. Cet incident illustre un phénomène croissant : les outils de sécurité eux-mêmes deviennent des vecteurs d’attaque.

Plumber, scanner de sécurité de vos pipelines CI/CD

Face à ce risque, Stéphane Robert et Aurélien Coget ont présenté lors de leur conférence Plumber, un outil open source qu’ils ont développé. Plumber effectue une analyse statique du code des fichiers de CI/CD (GitLab CI, GitHub Actions) pour détecter des configurations dangereuses : exécution de pipelines avec autorisation non vérifiée, utilisation de runners non éphémères ou utilisation de versions de paquets non pinées/signées. L’outil permet de donner une note selon différents critères et explique les failles de votre configuration. Les erreurs levées sont toujours rattachées à une règle, à un descriptif, et à un exemple pour vous aider à corriger.
Le site permet aussi de scanner un paquet public. Vous pouvez donc tester vous-même la qualité de vos dépendances open source.

Cependant, Plumber peut être source de tension avec des solutions de maintenance automatisées comme Renovate ou Dependabot, qui mettent à jour les dépendances en continu pour réduire la dette technique. Leur logique de « mettre à jour vite et souvent » peut en effet entrer en contradiction avec les impératifs de sécurité : une version récemment publiée peut contenir une vulnérabilité qui n’a pas encore été identifiée ni référencée, par exemple via une CVE.

Une solution palliative consisterait à définir une période de quarantaine : après la publication d’un nouveau paquet, les outils comme Renovate ou Dependabot pourraient l’isoler pendant x jours avant de l’intégrer automatiquement. Cette approche équilibre innovation et sécurité : elle préserve la productivité tout en ajoutant une couche de contrôle prudent.

Vous l’aurez compris, la CI/CD n’est plus seulement un levier de livraison : c’est un point critique de défense. La sécurité ne doit plus être une contrainte, mais un processus intégré, intelligent et négocié.

IA et souveraineté : reprendre en main nos systèmes d’informations

Dès qu’un produit est exposé sur Internet, il peut être attaqué pour le symbole qu’il représente (nation, entreprise, fonction à laquelle il répond…). Comme évoqué par Florian Toulemont, la France est devenue le 3ème pays le plus attaqué depuis les Jeux Olympiques de Paris.

La logique présentée lors de cette conférence est de chercher à se prémunir contre les attaques en essayant soi-même d’exploiter les systèmes que l’on développe. Ces pratiques étant strictement encadrées par la loi, toute tentative d’intrusion doit faire l’objet d’une autorisation formelle et préalable.

Au-delà des outils de CI qui vérifient les dépendances système et applicatives ou détectent les secrets intégrés en dur dans un projet, il est également utile de se former à des outils permettant d’identifier et de mieux comprendre la surface d’attaque d’un système :

• Nmap : pour scanner les ports des machines
• Ffuf : recherche de fichiers cachés (notamment des .git qui donnent l’historique de code)
• Owsap zap: pour scanner son projet vis à vis des plus grandes failles de sécurité
• Burp Suite : pour faire des tests d’intrusion

Les choix d’architectures peuvent également avoir un impact sur l’exposition des données. Par exemple, l’utilisation d’un UUID version 1 peut révéler certaines informations sur la machine ayant généré l’identifiant. De même, des identifiants incrémentaux rendent les ressources plus prévisibles et peuvent faciliter leur énumération par un attaquant ayant obtenu des droits supérieurs à la suite d’une élévation de privilèges.

Au-delà des outils d’analyse de vulnérabilités, la maîtrise du système d’information passe également par la souveraineté technologique. La gestion de l’infrastructure sur laquelle sont déployées les applications en constitue une composante essentielle. Lors de sa conférence, Ambre Person a ainsi présenté un panorama des différentes possibilités en matière de souveraineté technologique.

La souveraineté matérielle

Tout d’abord la souveraineté sur la partie matérielle. Les matières premières nécessaires à la fabrication des composants des serveurs sont en grande partie extraites et transformées en Asie. Les composants informatiques sont également largement fabriqués et assemblés par des acteurs asiatiques et américains, créant une forte dépendance de l’Europe vis-à-vis de ces deux continents.

Sur le plan de l’approvisionnement énergétique, l’Europe se dirige progressivement vers davantage d’indépendance grâce à son mix associant énergies renouvelables et nucléaire. Ce qui en fait même un acteur privilégié pour installer des datacenters avec une empreinte carbone faible lors de la phase de consommation des équipements.

La souveraineté logicielle

Sur la partie logicielle, les enjeux de souveraineté concernent les droits d’utilisation et la dépendance à un écosystème, qui peut conduire à une forme de vendor lock-in. La délivrance par l’ANSI du label SecNumCloud ne permet pas de garantir automatiquement une souveraineté sur tous les plans. Il garantit la conformité aux normes de sécurité françaises, mais ne contrôle ni l’origine du code, ni la localisation des serveurs de support, ni les licences logicielles sous-jacentes. Certains acteurs peuvent ainsi proposer une infrastructure opérée en Europe tout en s’appuyant sur des solutions logicielles américaines.

Voici, une représentation de la ségrégation des typologies de Cloud :

Niveau	Description	Souveraineté
1	Hyperscalers étrangers (AWS, Azure, GCP)	Aucune : données, traitement, code, infra… en dehors du contrôle national
2	Fournisseurs européens utilisant un logiciel étranger (ex : OpenStack sur AWS)	Souveraineté partielle : stockage en Europe, mais traitement dépendant d’un logiciel non souverain
3	Fournisseurs européens avec logiciel européen (ex : SCALE, OVH, Scaleway)	Souveraineté totale : stockage + traitement sous contrôle européen
4	Hébergement on-premise	Souverainté totale : stockage et traitement. Gestion supplémentaire de la commande et de l’entretien des serveurs.

Conclusion : IA, sécurité et souveraineté au cœur des échanges

Cette édition du BreizhCamp placée sous le thème de Matrix, a tenu toutes ses promesses. L’intelligence artificielle s’est imposée comme un sujet incontournable, notamment à travers deux enjeux majeurs : la sécurité et la souveraineté. Des sujets qui rappellent que l’adoption de l’IA ne peut se limiter à ses performances, mais doit également s’accompagner d’une réflexion sur la maîtrise de nos systèmes, de nos données et de nos dépendances technologiques.

De mon côté, je repars de cette édition avec quelques « devoirs de vacances » et plusieurs pistes concrètes à mettre en pratique dans les mois à venir :

• Revue des systèmes d’informations développés au sein du projet en testant le Top 10 de l’OWASP en se plaçant du point de vue de l’attaquant,
• Construction d’un référentiel commun d’usage de l’IA : normalisation des techniques prompts, partage de skills dans des marketplaces, mise en commun des agents,
• Intégration de l’outil Plumber au sein de la CI.