DevSecOps souverain : ce que les PME/ETI doivent vraiment retenir des recommandations ANSSI

# DevSecOps souverain : ce que les PME/ETI doivent vraiment retenir des recommandations ANSSI

Pendant des années, le DevSecOps a été présenté comme une affaire de grandes entreprises — celles qui peuvent se payer des équipes dédiées, des outils onéreux et des processus matures. Mais les attaques ciblant la chaîne logicielle ne font plus de discrimination. Et l'ANSSI, dans ses publications récentes, a clairement changé de cible : elle parle désormais aussi aux organisations de taille intermédiaire. Le message mérite d'être lu entre les lignes.

Un marché qui s'est structuré trop vite, trop mal

Le terme DevSecOps est aujourd'hui apposé sur à peu près tout ce qui touche au développement logiciel et à la sécurité. Des éditeurs américains ont massivement investi le segment avec des plateformes intégrées séduisantes — GitHub Advanced Security, Snyk, Veracode, la liste est longue. Ces outils fonctionnent. Mais ils posent, pour les PME/ETI européennes, une question que beaucoup de DSI ont longtemps éludée : où vont mes données de vulnérabilités ? Qui héberge le graphe de dépendances de mon code source ? Qui peut accéder, légalement ou sous contrainte réglementaire étrangère, à la cartographie de mes failles ?

Ce n'est pas une question abstraite. Les analyses SAST (test statique) et SCA (analyse de composition logicielle) produisent des artefacts extrêmement sensibles : la liste exacte des vulnérabilités connues dans votre application, les versions de bibliothèques utilisées, parfois des extraits de code. Confier ces données à une plateforme opérée sous juridiction américaine ou soumise au Cloud Act, c'est accepter une asymétrie d'information potentielle avec vos concurrents — ou vos adversaires.

L'ANSSI n'a pas attendu 2026 pour le dire. Mais elle le dit désormais avec une précision opérationnelle accrue, notamment dans le prolongement de ses travaux sur la sécurité de la chaîne logicielle (supply chain software) et ses recommandations autour de l'homologation des systèmes d'information.

Ce que l'ANSSI dit — et ce qu'elle ne dit pas

L'agence a publié ces dernières années plusieurs documents structurants : ses recommandations sur la sécurité des pipelines CI/CD, ses guides sur la gestion des dépendances open source, et plus récemment ses travaux sur la qualification des outils de développement sécurisé. Le fil conducteur est cohérent : intégrer la sécurité au plus tôt dans le cycle de développement, automatiser les contrôles, et maîtriser la chaîne de confiance de bout en bout.

Mais l'ANSSI ne dit pas « utilisez tel outil plutôt que tel autre ». Ce n'est pas son rôle, et ce serait une erreur de lire ses recommandations comme un cahier des charges prescriptif. Ce qu'elle fait, c'est poser un cadre d'exigences — et ce cadre a des implications directes sur les choix d'outillage.

Concrètement, trois points ressortent pour les organisations de taille intermédiaire :

La maîtrise du pipeline CI/CD est un prérequis de sécurité. Un pipeline qui orchestre les tests, les builds et les déploiements est aussi une surface d'attaque. Les compromissions de SolarWinds ou de l'écosystème npm ont montré que c'est précisément là que les attaquants cherchent à s'introduire. L'ANSSI insiste sur la nécessité de contrôler qui peut modifier un pipeline, de tracer les modifications, et de valider l'intégrité des artefacts produits.

Les dépendances open source doivent être gérées, pas subies. La plupart des PME/ETI qui développent des logiciels intègrent des centaines de bibliothèques tierces. Peu ont une visibilité réelle sur les versions utilisées, leurs vulnérabilités connues et les conditions de leur mise à jour. Un SBOM (Software Bill of Materials) n'est plus un concept académique : c'est un document opérationnel dont l'ANSSI recommande la production systématique.

La qualification des outils compte. Tous les scanners de vulnérabilités ne se valent pas, pas seulement en termes de détection, mais en termes de confiance. Pour les organisations qui traitent des données sensibles ou qui visent une certification (SecNumCloud, HDS, ISO 27001 renforcée), l'origine et le modèle de déploiement des outils de sécurité entrent dans l'équation.

Pourquoi les PME/ETI sont dans une position particulièrement inconfortable

Les grands groupes ont des équipes dédiées à la veille réglementaire. Ils peuvent absorber le coût d'une migration d'outillage, financer une expertise interne sur les référentiels ANSSI, négocier des clauses contractuelles avec leurs éditeurs. Les PME/ETI, elles, naviguent souvent avec un DSI ou un RSSI qui cumule les casquettes, des budgets sous tension et des équipes de développement qui ont déjà leurs habitudes — souvent autour d'outils américains parfaitement fonctionnels.

Le vrai problème n'est pas technique. Il est organisationnel et culturel. Introduire la sécurité dans les processus de développement sans ralentir les équipes, sans créer de friction excessive, sans démotiver des développeurs qui voient dans chaque nouveau contrôle une source de blocage — c'est un défi de management autant que de sécurité.

Et sur ce point, les recommandations de l'ANSSI sont parfois perçues comme trop théoriques par les praticiens. Elles décrivent un état cible ambitieux. Elles donnent moins de réponses sur le chemin pour y arriver quand on part de zéro avec deux développeurs et un budget serré.

L'angle souveraineté : réel, mais à ne pas surestimer

Sur la souveraineté, soyons honnêtes : la question n'est pas binaire. Rejeter en bloc les outils américains au nom de la souveraineté serait aussi absurde que d'ignorer le problème. GitLab, par exemple, propose une version auto-hébergée déployable sur infrastructure européenne — et c'est une option que de nombreuses ETI ont sérieusement étudiée ces dernières années, précisément parce qu'elle offre un compromis acceptable entre fonctionnalité et maîtrise.

Du côté français, des acteurs comme Cyberwatch ou Sysdig (via ses partenaires européens) adressent des segments spécifiques du marché DevSecOps. Mais il faut être lucide : l'écosystème outillage DevSecOps souverain est encore fragmenté. Il n'existe pas aujourd'hui de plateforme française ou européenne qui couvre de bout en bout ce que proposent les solutions américaines les plus intégrées. C'est une réalité de marché, pas un jugement de valeur.

Ce qui change concrètement en 2026, c'est que cette lacune est de moins en moins acceptable du point de vue réglementaire. NIS2, le règlement européen sur la cyber-résilience (CRA), et les exigences croissantes des donneurs d'ordre vis-à-vis de leurs fournisseurs font que la question « où hébergez-vous vos outils de sécurité ? » commence à apparaître dans les audits et les appels d'offres. Ce n'est plus une question de principe idéologique : c'est une question de qualification fournisseur.

Ce que ça implique concrètement pour un DSI en 2026

Pas de recette magique ici, mais quelques réflexions de fond qui méritent d'être posées en CODIR ou en comité de direction IT.

Commencer par cartographier, pas par acheter. Avant d'évaluer un outil DevSecOps, il faut savoir ce qu'on a. Quels sont les pipelines existants ? Qui les maintient ? Quelles sont les dépendances critiques ? Cette cartographie, que beaucoup d'organisations n'ont pas faite sérieusement, est le point de départ incontournable. Et elle ne nécessite pas de budget — elle nécessite du temps et de la méthode.

Traiter le SBOM comme un actif, pas comme une contrainte. Produire et maintenir un Software Bill of Materials, c'est se donner la capacité de réagir vite lors d'une vulnérabilité critique comme Log4Shell. Les organisations qui avaient cette visibilité en décembre 2021 ont répondu en heures. Les autres en semaines. L'argument ROI est là, même si je me garderai bien de vous donner un chiffre.

Poser la question de l'hébergement des outils de sécurité lors de chaque renouvellement contractuel. Pas pour exiger systématiquement du souverain, mais pour documenter le choix et ses implications. Si votre RSSI peut expliquer pourquoi vous hébergez votre scanner de vulnérabilités chez un opérateur américain et quels sont les garde-fous, c'est une décision assumée. Si personne ne peut répondre à cette question dans votre organisation, c'est un problème.

Ne pas attendre la perfection pour commencer. L'erreur classique est de vouloir implémenter un pipeline DevSecOps complet et souverain d'un coup. La réalité des PME/ETI, c'est qu'une amélioration progressive — introduire un scan SCA basique dans le pipeline existant, former les développeurs aux dépendances critiques, mettre en place une politique de mise à jour documentée — vaut infiniment mieux que le projet ambitieux qui ne démarrera jamais faute de budget validé.

Ce débat ne fait que commencer

L'ANSSI a ouvert un cadre. L'Union européenne, via le Cyber Resilience Act, va imposer des obligations concrètes aux éditeurs de logiciels qui touchent le marché européen — y compris les PME/ETI qui vendent des produits avec des composants logiciels. Le DevSecOps n'est plus un choix d'organisation avancée : il va devenir une condition d'accès au marché pour une partie croissante du tissu industriel européen.

La vraie question n'est pas « est-ce qu'on adopte le DevSecOps ? » mais « à quelle vitesse allons-nous devoir le faire, et avec quels outils ? ». Et sur cette deuxième partie, l'écosystème européen a encore du chemin à faire.

Un DSI qui attend que le marché souverain soit mature avant de bouger prend le risque d'être en retard d'un cycle réglementaire. Celui qui s'enferme dans une logique purement idéologique de souveraineté à tout prix risque de fragiliser son organisation opérationnellement. Entre ces deux postures, il y a un espace de pragmatisme raisonné — et c'est précisément là que les décideurs IT européens vont devoir travailler dans les prochaines années.