"Agentic SecDevOps" ou le SecDevOps Agentique, est-il fait pour vous?

Qu’est-ce que c’est?

Comme il est de mon habitude, prenons un moment pour examiner les « parties constitutives nues et essentielles » de ce qu'est Agentic DevOps, et voyons comment nous les alignons sur l'état d'esprit de SecDevOps.

 

« Agentic DevOps » de Microsoft, concepts clés :

• « Agentic DevOps » positionne les agents d’IA (comme GitHub Copilot) comme des collaborateurs actifs dans le cycle de vie du développement et des opérations, non seulement des assistants, mais des participants.
• Ces « agents » sont intégrés dans les flux de travail des développeurs
  • Suggérer du code
  • Générer des tests unitaires
  • Assistance avec les configurations YAML CI/CD
  • Potentiellement même en surveillant les plateformes, aidant à trier les incidents.
• L’intégration Azure/Devops et GitHub vise à créer une boucle transparente où l’IA connecte les pipelines de développement, de test, de déploiement et d’observabilité.
• Le modèle encourage l’automatisation axée sur l’intention, vous décrivez ce que vous voulez accomplir et l’agent aide à échafauder ou à mettre en œuvre la solution.

Agentic DevOps : l’IA c'est un joueur d'équipe?

Nous l’avons tous déjà vu : les démos où GitHub Copilot semble terminer votre code avant même que vous ayez fini de taper votre pensée. Et maintenant, avec la vision Agentic DevOps de Microsoft, il ne s’agit pas seulement d’écrire du code plus rapidement, il s’agit de changer complètement la façon dont nous développons, testons, déployons et exécutons des logiciels.

Je l’utilise personnellement, tout le temps. C'est assez étonnant de voir comment il peut « couper dans le gras » de l'écriture de code qui serait autrement évident, voire fastidieux. C’est-à-dire que certaines des routines que nous écrivons sont simplement des algorithmes « fréquemment utilisés » et « bien connus ». Juste avec des paramètres différents ou d'utres variables. 

Vous pouvez également demander aux LLM de rédiger des applications entières. Et il fait parfois un travail raisonnable. Ce « parfois » cependant... Qui sait quand il fera ou ne fera pas les choses correctement? Plus il faut produire de code, plus il est probable qu'il contienne un bogue majeur.

Pour être honnête, on peut dire la même chose du code que nous écrivons nous-mêmes. Mais ce qui est prévisible, c’est notre faillibilité. En fait, nous l’incluons dans nos processus, sachant qu'on est faillible, on se valide. Nous pourrions être tentés de supprimer cela de nos processus si nous faisons appel à la IA pour le faire.

Donc, plus elle est fiable, plus nous nous y fierons. Maintenant, est-ce un atout ou un nouveau risque?

Est-ce la révolution dont nous avons besoin, ou simplement une autre couche de complexité déguisée en automatisation?

En tant que personne qui travaille à l’intersection de la sécurité, des opérations et de la culture DevOps depuis un certain temps déjà, j’observe cette tendance avec enthousiasme et prudence.

Déballons le tout.

Le bon : pourquoi c’est important

1. Accélération des tâches répétitives
   Vous écrivez un YAML passe-partout? Structurer ce script de déploiement de Bicep? Copilot réduit déjà des heures de ces tâches. Ce n’est pas anodin, cela permet aux équipes de se concentrer sur la conception réelle, le risque et la valeur pour l’utilisateur.

2. Renseignement sur les incidents
   L'intégration de l'observabilité, des logs et des données d'incident dans la portée de Copilot pourrait signifier que les agents d'IA peuvent aider à identifier plus rapidement les causes profondes, peut-être même à qualifier les problèmes pour déclencher des correctifs automatisés.

3. Joindre les silos
   Une plateforme partagée où le code, le déploiement et la surveillance sont tous augmentés par l’IA pourrait réduire les frictions entre les développeurs, les opérations et la sécurité, si elle est adoptée correctement. Cela pourrait entraîner une reconnaissance du besoin constant d’évaluation par les pairs en tant que processus, au lieu de le considérer comme une critique systématique.

4. Synergie d’ingénierie de plateforme
   Cette vision s’aligne bien sur les plateformes de développement internes (IDP), les IA pourraient aider les développeurs à développer plus facilement les constructions, l’infrastructure et les pipelines en libre-service, si les garde-fous sont correctement appliqués.

Les mises en garde (quelques-unes) : Du point de vue de SecDevOps

1. L’automatisation sans compréhension est dangereuse
   Si vous ne comprenez pas code YAML que Copilot vient d’écrire, vous ne pouvez pas le sécuriser. La confiance aveugle dans les Systèmes Agentiques crée des angles morts, en particulier dans la configuration, la gestion des secrets et les autorisations. Ne parlons même pas du Vibe coding, sinon je m'énèrve. Comprendre le code est essentiel pour maintenir un écosystème Zero Trust.

2. Sécurité par suggestion != Secure by Design
   Les agents de l’IA peuvent suggérer des pratiques exemplaires, mais c’est toujours aux humains de valider, d’appliquer les politiques et de penser de manière critique. Le décalage à gauche (shift left) devient superficiel si nous le déplaçons simplement sur les épaules de Copilot. Cela ne couvre peut-être pas toutes vos bases non plus. Les gens doivent donc faire mieux que de combler les lacunes que l’IA pourrait créer, mais plutôt faire la liste complète des exigences dès le départ.

3. Dérive des agents et conformité aux politiques
   Qui vérifie ce que l’agent a changé? Est-il versionné? Exploité? Évalué par des humains? Dans un monde axé sur la conformité, la traçabilité et l’explicabilité ne sont pas négociables: La Confiance Zéro (Zero Trust) doit s’appliquer et s’appliquera toujours, et Copilot sera le premier à être vérifié à chaque tournant.

4. Burnout par pseudo-accélération
   Il y a un risque réel que l’accélération perçue masque la charge cognitive réelle. Les équipes peuvent se sentir obligées de suivre la cadence l’agent, ou compense pour la masse d'informations produite, sans avoir le temps de comprendre, de remanier ou de respirer. Le volume de ce que les outils d’IA peuvent produire pourrait être écrasant, alors continuons à utiliser le sens de la « meilleure valeur » que DevOps propose toujours.

5. Les gens sont toujours la Plateforme
   La pérennité n'est pas seulement pour l'écologie: Il s'agit de former des équipes qui durent. Si nous déchargeons trop de la réflexion sur les outils, nous risquons d’aliéner les gens de leur métier. Et vice versa : si les outils sont disponibles et que nous en interdisons tout simplement l'utilisation, cela peut aussi causer une aliénation envers nos penseurs ou enthousiastes progressistes.

6. Gouvernance avec reconnaissance de modèles
   Il peut être tentant de demander à l’IA de rechercher des modèles qui enfreindrait nos règles de gouvernance. Mais compter sur elle pour le déceler, est à nos risques et périls. Bien que les faux positifs puissent désensibiliser les équipes quant à des incidents potentiels réels, les résultats « aiguilles dans une botte de foin », où l’IA détecte enfin quelque chose de pertinent, pourraient nécessiter plus d’efforts pour repérer et analyser qu'il en vaille la peine. Cette approche doit être soigneusement évaluée en ce qui concerne la valeur finale de « l’IA dans la gouvernance ».

7. Les Agents de l'IA, sont des entités étrangères 
   Jusqu' à présent, du point de vue de la proposition de Microsoft, nous pouvons en déduire que nous devons leur confier notre code et nos agents et leurs instructions spécifiques. C'est leur modèle d'affaires, donc je ne les blâme pas pour cela. Non seulement le volume de cas d’utilisation renforce leur offre de produits et de services, mais il peut également exposer notre propriété intellectuelle et même des failles de sécurité. Vous devriez donc envisager l’auto-hébergement d’une partie ou de la totalité des composants de votre ALM, lors de l’intégration d’Agentic SecDevOps chez vous.  Après tout, l'hébergement de modèles d'IA comme phi4-reasoning est tout à fait faisable au niveau de l'entreprise. Théoriquement, Microsoft n'a pas du tout, à figurer dans la boucle. 

Où cela s’aligne sur nos valeurs

Le modèle DevOps culturel dont nous avons parlé, la propriété partagée, l’empathie interfonctionnelle, la pérennité, peut fonctionner à merveille avec Agentic DevOps si nous :

• Utilisons l’IA pour augmenter , et non pour remplacer, les pratiques d’équipe.
• Insistons sur « l’explicabilité », la traçabilité et la validation à chaque étape.
• Enseignons aux équipes comment remettre en question les résultats de Copilot, pas seulement les accepter.
• Préservons le contrat social : l’automatisation sert les gens, et non l’inverse.

 Alors... est-ce l’avenir?

Peut-être. Pour ma part, j’ai hâte d’y arriver. Mais seulement si nous intégrons des principes axés sur l’humain dans la façon dont nous l’adoptons. L’IA et les LLM sont d’excellents outils pour générer des idées et tester certaines des nôtres, mais la pensée critique est reste le domaine des personnes réelles.

Oui, l’IA façonnera certes, la manière dont nous créons et exploiterons les solutions technologiques. Mais que cela donne du pouvoir ou éclipse les gens, c’est toujours à nous de décider. Une chose est certaine, si l'AI ne travaille pas pour nous, nous travaillerons pour elle. Je ne dis pas cela à la manière totalement dystopique d'un mauvais film de science-fiction, mais dans le sens où il peut être plus difficile d'y adapter ce que nous faisons, si nous ne concevons pas ses mises en garde dans nos méthodes, dès le départ.

À mon avis, Agentic SecDevOps utilisera ces outils comme si nous avions des juniors très enthousiastes  qui ont une variété (beaucoup de) d’opinions à partager. Mais ces opinions nécessitent un examen critique. Et par le volume des propositions qu’elles peuvent se permettre, elles ne peuvent être ignorées : nous devons les considérer.

Maintenant, demandez-vous à vous et à votre équipe : 

•  Allons-nous utiliser cela pour construire plus rapidement et mieux bâtir? 
• Ou allons-nous nous conformer à une politique qui dit que nous devons l'utiliser, parce qu'elle a été considérée comme « le nouveau paradigme »?

L’une de ces voies mène à la résilience. L’autre mène à l’épuisement professionnel. Et peut-être aussi un désengagement complet de l’équipe.

Choisissons judicieusement.

Qu'en pensez vous?