"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?

Is Agentic SecDevOps for you?

What is it?

As usual. let's take a moment to look at the "bare essential constituant parts" of what Agentic DevOps is, and let's see how we align them to the SecDevOps mindset.

Microsoft’s "Agentic DevOps", Key Concepts:

• "Agentic DevOps" positions AI agents (like GitHub Copilot) as active collaborators in the development and operations lifecycle, not just assistants, but participants.
• These "agents" are embedded in developer workflows 
• suggesting code
• generating unit tests
• assisting with CI/CD YAML configs
• even watching platforms, helping triage incidents.
• Azure/Devops and GitHub integration aims to create a seamless loop where AI connects dev, test, deployment, and observability pipelines.
• The model encourages intent-driven automation, you describe what you want to achieve, and the agent helps scaffold or implement the solution.

---

Agentic DevOps: Is AI Ready to Be a Team Player?

We’ve all seen it by now: the demos where GitHub Copilot seems to finish your code before you even finish typing your thought. And now, with Microsoft’s Agentic DevOps vision, it’s not just about writing code faster, it’s about changing how we develop, test, deploy, and run software altogether.

I use it personally, all the time. It's quite stunning how it can "trim the fat" off writing code that would otherwise be obvious if not tedious. That is to say, some of the routines we write are simply "frequently used" and "well known" algorithms. Just different parameters or variables. 

You can ask LLMs to write whole applications too. And it sometimes does a reasonable job. That "sometimes" though...who knows when it will, or won't do things properly? The more code it is required to produce the more likely it's going to contain a major bug.

To be fair, the same can be said about the code we write ourselves. But what is predictable is our fallibility. We include this in our processes as a matter of fact. We might be tempted to trim this out of our processes if we involve an AI to do it.

So, the more reliable it is, the more we will rely on it. Now, is that an asset or a new risk?

Is it the revolution we need, or just another layer of complexity dressed up as automation?

As someone who’s worked at the intersection of security, operations, and DevOps culture for a while now, I’ve been watching this trend with both excitement and caution.

Let’s unpack it.

---

The Good: Why This Matters

1. Acceleration of Repetitive Tasks
   Writing boilerplate YAML? Structuring that Bicep deployment script? Copilot is already shaving hours off those tasks. That’s not trivial, it frees teams to focus on actual design, risk, and user value.

2. Incident Intelligence
   The integration of observability, logs, and incident data into Copilot's scope could mean AI agents can help identify root causes faster, maybe even qualify the issues for triggering automated remediations.

3. Bridging Silos
   A shared platform where code, deployment, and monitoring are all AI-augmented could reduce friction between devs and ops, if adopted correctly. It could bring a consistent need for peer reviewing as a process, instead of having the process viewed as systematic criticism.

4. Platform Engineering Synergy
   This vision aligns well with Internal Developer Platforms (IDPs), the AIs could help developers self-serve builds, infra, and pipelines more easily, if guardrails are properly enforced.

---

The Caveats (a few): From a SecDevOps Perspective

1. Automation Without Understanding Is Dangerous
   If you don’t understand the YAML Copilot just wrote, you can’t secure it. Blind trust in agentic systems creates blind spots, especially in config, secrets handling, and permissions. Don't even get me started on Vibe coding. Understanding code is critical to maintain a Zero Trust ecosystem.

2. Security by Suggestion != Secure by Design
   AI agents might suggest best practices, but it’s still up to humans to validate, enforce policies, and think critically. Shift-left becomes shallow if we just shift it onto Copilot’s shoulders. It may not cover all you bases either. So people must do better than fill in the gaps that AI might create, but instead, make the full list of requirements upfront.

3. Agent Drift and Policy Compliance
   Who’s auditing what the agent changed? Is it versioned? Logged? Reviewed by humans? In a compliance-driven world, traceability and "explainability" are non-negotiable. Zero trust must and will still apply, and Copilot will be the first to be verified at every turn.

4. Burnout via Pseudo-Acceleration
   There’s a real risk of perceived acceleration masking actual cognitive load. Teams might feel pressured to "keep up with the agent" without having time to understand, refactor, or breathe. The sheer volume of what the AI tools can output could be overwhelming, so lets keep using the sense of "best value" that DevOps always proposes.

5. People are still the Platform
   Sustainability isn't just ecological, it's about building teams that last. If we offload too much thinking to tools, we risk alienating people from their craft. And vice-versa: if the tools are available and we simply forbid it's use, it can also cause alienation towards our progressive thinkers or enthusiasts.

6. Governance with pattern recognition
   It may be tempting to have the AI look out for patterns that break our governance rules. But relying on it to do so, is at our own peril. As much as false positives could desensitize out teams as to real potential incidents, "needles in a haystack" outcomes, where AI does finally detect something pertinent, might require more effort to parse that it is worth. This approach must be carefully evaluated as far as the final value of "AI in governance".

7. Agents are foreign entities
   So far, from the perspective of Microsoft's proposition, we can infer that we must entrust our code and agents and their specific instructions to their care. That's their business model so I don't blame them for it. Not only does the volume of use cases, reinforce their product and service offering, but it may also expose intellectual property and even security flaws. So you might want to consider "self hosting" part of or all of the components of your ALM, when integrating Agentic SecDevOps. After all, hosting AI models like phi4-reasoning is completely feasible at enterprise level. Theoretically, Microsoft doesn't have to figure in the loop, at all. Let's keep that in mind.
   

---

Where It Does Align with Our Values

The cultural DevOps model we’ve talked about, shared ownership, cross-functional empathy, sustainability, can work beautifully with Agentic DevOps if we:

• Use AI to augment, not replace, team practices.
• Insist on "explainability", traceability, and validation at every step.
• Teach teams how to challenge Copilot’s output, not just accept it.
• Preserve the social contract: automation serves the people, not the other way around.

---

So… Is This the Future?

Maybe. I for one, am looking forward to it. But only if we embed human-first principles into how we adopt it. AI and LLMs are great tools to generate ideas and test some of our own but critical thinking is still the realm of real people.

Yes, AI will shape how we build and run software. But whether it empowers or overshadows people, that’s still up to us. One thing is for certain, if is not working for us, we will be working for it. I don't mean this in the totally dystopian fashion of a bad sci-fi movie, but in the sense it may be more trouble adapting what we do, to it, if we don't design its caveats in our methods, from the get-go.

In my view, Agentic SecDevOps is using these tools like we have some very enthusiastic juniors that have a (quite a few) variety of opinions to share. But those opinions need critical scrutiny. And by the sheer volume of the propositions they can afford, they cannot be ignored: we must consider them.

Les deux facettes du DevOps : gourou de la technologie versus une nouvelle culture

De quoi s’agit-il?

Au cours des derniers mois, en examinant le marché de l’emploi DevOps , une tendance claire s’est manifestée: de nombreuses organisations considèrent encore DevOps comme deux intérêts distincts. Ci-dessous, je vais essayer de les démonter et de vous faire voir ce qui les fait fonctionner. Gardez à l’esprit que DevOps ici, c’est aussi très bien SecDevOps.

Bien que pour SevDevOps, il y ait très peu de sensibilisation (pour ne pas dire d'intérêt) de ses avantages, les raisons en sont exactement les mêmes et c'est ce dont nous parlons ici: tout est balancé dans le même tas. Et donc perdus dans la chaîne de valeur.

Posture 1: DevOps en tant que rôle spécialisé

Tout d’abord, et le plus souvent, je vois DevOps être promu comme un rôle de génie distinct, quelqu’un pour « combler le fossé » entre les développeurs qui créent des fonctionnalités et les administrateurs système qui s’immiscent dans l’infrastructure. DevOps arrive a maintenir son titre ici parce que le rôle se situe bien entre les deux: Dev et Ops.

• Forte demande, salaire élevé : Les rôles étiquetés « DevOps Engineer » restent courants. Les données de l’enquête montrent que 29% des équipes informatiques ont récemment embauché des ingénieurs DevOps, avec des salaires allant de ≈ 84 k$ US à 126 k$ US (pour 1 à 5 ans d’expérience) (Spacelift, Brokee).
• Rareté des compétences : 37% des leaders technologiques mentionnent DevOps/DevSecOps comme leur principal déficit de compétences (Spacelift).
• Chaînes d’outils spécialisées : La boîte à outils typique, Docker, Kubernetes, pipelines CI/CD, est solidement perchée sur les épaules de ces « spécialistes des lacunes » (Spacelift). 

Ce modèle est vite à démarrer: embauchez quelqu’un qui possède des "pipelines", de l’automatisation, de la conteneurisation et des déploiements infonuagiques. Les objectifs sont clairs. Mais il y a un danger: la concentration des responsabilités.

• La personne (ou l’équipe) DevOps devient un nouveau point de défaillance ou de goulot d’étranglement .
• Les transferts sont fréquents : développement de fonctionnalités à DevOps à infra. Cela peut ralentir la livraison et créer des frictions de communication.
• Du point de vue de la pérennité, il risque d’entraîner l’épuisement professionnel, la surspécialisation et la dépendance malsaine à l’égard de quelques personnes clés.
• Surtout, cela crée également un nouveau silo. Une chose que la plupart des amateurs de DevOps confirmeraient est indésirable.

Pour moi, il s'agit d'une appropriation.  DevOps a certainement prouvé qu'il était sexy là où il a été correctement mis en œuvre. Donc, parsemer le marché du travail avec le terme tout en trouvant une excuse pour lancer cette responsabilité sur une nouvelle "faction", semble un peu fourbe. Mais à proprement parler, c'est un de mes agacements très personnels.

Posture 2: DevOps comme paradigme culturel

L'alternative n'est pas mythique: mais c'est le changement holistique et culturel où DevOps est adopté par toute l'équipe.

• Propriété par les équipes : Les développeurs créent, déploient et exploitent leurs services avec intention.
• La responsabilité partagée élimine les goulots d’étranglement et les points de défaillance uniques.
• L’ingénierie de la plateforme et les plateformes de développement internes (IDP) permettent le libre-service: les développeurs obtiennent ou construisent des chaînes d’outils, des pipelines et des environnements à la demande, et non par l’intermédiaire d’un intermédiaire (Baytech Consulting, Wikipédia).
• Ce modèle s’aligne sur les valeurs de DORA : les équipes deviennent une élite, avec une livraison continue en moins d’une journée, une culture irréprochable et des équipes autonomes (Cortex), la sécurité et les opérations sont intégrées à leur travail, donc la coopération dès le départ.

De plus, en 2025, nous voyons le DevOps évoluer :

• AI/ML/LLM s’intègrent dans les pipelines pour la gestion prédictive des incidents, la génération d’autotests et les systèmes d’auto-réparation (DevOps.com, Baytech Consulting).
• DevSecOps intègre la sécurité dans CI/CD, réduisant les frictions et atténuant les risques tôt (DevOps.com, H2K Infosys).
• Les équipes de la plateforme se concentrent sur l’expérience des développeurs, pas seulement sur l’outillage, en mesurant le succès en fonction du débit, de la stabilité et de la satisfaction (Baytech Consulting, Wikipédia).
• La pérennité gagne du terrain: l’accent est mis sur la culture, le cadre CAMS et les cadres décisionnels pour intégrer la maintenabilité et la viabilité à long terme (arXiv).

Comme je l'ai déjà dit, si ce n'est pas simplement pour l'aspect de la pérennité, cela s'aligne beaucoup mieux avec ce que DevOps a à offrir. Pour faire simple*, il ne s'agit pas de travailler plus fort, mais de travailler mieux. Si vous ne pouvez pas amener vos développeurs à s'engager dans ce changement, c'est probablement le point que vous n'avez pas assez poussé.

Ce n’est pas tant un effet secondaire, cela leur rend la vie plus facile, meilleure.

*Simple ne remplace pas facile, gardez ça en tête.

Ma propre évaluation des deux approches

Aspect	Rôle de spécialiste DevOps	DevOps comme culture et ingénierie de plateforme
Il est temps de commencer	Rapide – embauchez quelqu’un qui « est propriétaire »	Plus lent, nécessite un changement culturel et des outils
Modèle de dépendance	Point de défaillance centralisé et unique	Responsabilité décentralisée et partagée
Goulots d’étranglement	Élevée – un spécialiste devient un goulot d’étranglement	Faible – les pipelines libre-service réduisent la friction
Évolutivité	Limité – nécessite plus de spécialistes au fur et à mesure que les équipes grandissent	Plus élevé – les plateformes partagées évoluent horizontalement
Résilience pérenne	Fragile – risque d’épuisement professionnel et de silos	Robuste – l’appropriation et la collaboration favorisent la santé
Intégration de la sécurité	Géré par un ou plusieurs rôles spécialisés	Intégré par défaut dans toutes les équipes
Innovation et autonomie	Contraintes, les dépendances ralentissent les progrès	Les équipes habilitées itèrent rapidement

Mon point de vue: La pérennité d’abord

Si vous avez lu mes autres articles dans le passé, vous devez commencer à me connaître: si ce n'est pas pérenne, j'aurai du mal à le défendre. Donc, comme dans les articles précédents, j’ai mis l’accent sur la pérennité, les développements que nous pouvons maintenir, évoluer et dont nous dépendons à long terme. Le modèle DevOps centré sur les spécialistes est opportun, mais il comporte des risques périlleux pour la pérennité: dépendance humaine excessive, connaissances cloisonnées et fragilité des processus.

Le modèle DevOps culturel, alimenté par la propriété de l’équipe et l’ingénierie de la plateforme, est plus difficile à atteindre, mais il correspond directement à cette pérennité que je vous souhaite. Les services deviennent auto-renforcés :

• Moins d’épuisement professionnel: La responsabilité partagée dilue la charge.
• Moins de goulots d’étranglement: Les outils en libre-service responsabilisent les équipes.
• Résilience culturelle: Les pratiques et les normes survivent aux changements de personnel.

Maintenant répondez-moi ceci: Lequel offre le meilleur rapport qualité-prix?

• Est-ce que l’embauche d’un autre expert est une victoire rapide, mais un passif à long terme?
• Investir dans la transformation culturelle et l’ingénierie des plateformes est-il plus gourmand en ressources au départ, mais beaucoup plus résilient et pérenne?

En d’autres termes : valorisons-nous les solutions rapides ou les systèmes de construction (humains et techniques) qui perdurent?

Quelle a été votre expérience? Vos efforts DevOps sont-ils centrés sur un modèle de transition ou intégrés à vos équipes? Quel chemin a le plus contribué aux opérations pérennes à grande échelle?

Poursuivons la conversation et construisons des systèmes DevOps qui responsabilisent d’abord les gens, puis les outils.
 

À venir :

Agentic SecDevOps, est-ce pour vous?

The Two Faces of DevOps: Tech guru vs. Culture

What is all this about?

Over the past months, as I’ve scanned the DevOps job market, one clear pattern emerged: many organizations still treat DevOps as two distinct interests. Below I'll try to take them apart and make you see what makes them tick. Keep in mind that DevOps here, is also very much also SecDevOps.

Although for SevDevOps, there is very little awareness (not to say, interest) of it's benefits. The reasons for that are exactly, because if what we are talking about here: it all gets thrown in for good measure. And therefore lost in the value chain.

Posture 1: DevOps as a Specialized Role

First and most frequently, I see DevOps being promoted as a distinct engineering role, someone to “bridge the gap” between developers who build features and SysAdmins who meddle with infrastructure. DevOps tenuously holds it's title here because they do sit between the two Dev and Ops.

• High demand, high pay: Roles labeled “DevOps Engineer” remain common. Survey data shows 29 % of IT teams recently hired DevOps engineers, with salaries ranging from ≈ US $84 k–126 k (for 1–5 years’ experience) (Spacelift, Brokee).
• Skill scarcity: 37 % of tech leaders list DevOps/DevSecOps as their top skills gap (Spacelift).
• Specialized tool chains: The typical toolkit, Docker, Kubernetes, CI/CD pipelines, is solidly perched on the shoulders of these “gap specialists” (Spacelift).

This model boots up fast: hire someone who owns pipelines, automation, containerization, and cloud deployments. Goals are clear. But there’s a danger, concentration of responsibility.

• The DevOps person (or team) becomes a new single point of failure or bottleneck.
• Handovers are frequent: feature dev to DevOps to infra. This can slow delivery and create communication friction.
• From a sustainability perspective, it risks burnout, over-specialization, and unhealthy dependencies on a few key individuals.
• Importantly, it also creates a new silo. A thing most DevOps enthusiasts would confirm, is undesirable.

To me, this is an appropriation.  DevOps certainly has proven it's sexiness where it has been properly implemented. So peppering the job market with the term while just finding an excuse to dump this responsibility on a new faction, seem a bit disingenuous. But strictly that's a peeve of mine.

---

Posture 2: DevOps as Cultural Paradigm

The alternative isn’t mythical: but it's the holistic, cultural shift where DevOps is embraced by the entire team.

• Ownership by teams: Developers build, deploy, and operate their services with intent.
• Shared accountability removes bottlenecks and single points of failure.
• Platform engineering and Internal Developer Platforms (IDP) enable self-service: developers get or build toolchains, pipelines, and environments on demand, not via a middleman (Baytech Consulting, Wikipedia).
• This model aligns with DORA values: teams become elite, with continuous delivery in under a day, blameless culture, and empowered teams (Cortex), security and operations are embedded in their work, so cooperation from the get-go.

Moreover, in 2025 we’re seeing DevOps evolve:

• AI/ML/LLM are weaving into pipelines for predictive incident management, auto-test generation, and self-healing systems (DevOps.com, Baytech Consulting).
• DevSecOps embeds security into CI/CD, reducing friction and mitigating risk early (DevOps.com, H2K Infosys).
• Platform teams focus on developer experience, not just tooling, measuring success by throughput, stability, and satisfaction (Baytech Consulting, Wikipedia).
• Sustainability is gaining traction: emphasis on culture, CAMS framework, and decision frameworks to embed maintainability and long-term viability (arXiv).

As I said before, if it isn't simply for the sustainability aspect, this aligns much better with what DevOps has to offer. To put it simply*, it's not working harder it's working smarter. If you cannot get your developers to engage in this change, this is probably the point you didn't make abundantly clear, enough.

Not so much as a side effect, it makes their lives easier, better.

*Simple is not a substitution for easy, remember that.

---

My own evaluation of the Two Approaches

Aspect	DevOps Specialist Role	DevOps as Culture & Platform Engineering
Time to start	Fast – hire someone who “owns it”	Slower, requires cultural change and tooling
Dependency model	Centralized, single point of failure	Decentralized, shared responsibility
Bottlenecks	High – one specialist becomes bottleneck	Low – self-service pipelines reduce friction
Scalability	Limited – needs more specialists as teams grow	Higher – shared platforms scale horizontally
Sustainable resilience	Fragile – burnout and silos risk	Robust – ownership and collaboration foster health
Security integration	Managed by specialist role(s)	Integrated by default across teams
Innovation & autonomy	Constrained, dependencies slow progress	Empowered teams iterate rapidly

---

My Perspective: Sustainability First

If you have read my other posts in the pasts, you must be beginning to know me: If it's not durable, I'm going to find it difficult to advocate for it. So as in earlier articles, I’ve emphasized sustainability, developments we can maintain, evolve, and depend on long-term. The specialist-centric DevOps model is expedient, but it carries perilous sustainability risks: excessive human dependency, siloed knowledge, and process fragility.

The cultural DevOps model, powered by team ownership and platform engineering, is harder to reach, but it maps directly onto sustainability. Services become self-reinforcing:

• Less burnout: Shared responsibility dilutes the load.
• Fewer bottlenecks: Self-service tooling empowers teams.
• Cultural resilience: Practices and standards survive personnel changes.

---

Riddle me this: Which Offers Better Value?

• Is hiring another expert a quick win, but a long-term liability?
• Is investing in cultural transformation and platform engineering more resource-intensive up-front, but far more resilient and sustainable?

In other words: Do we value fast fixes, or building systems (both human and technical) that endure?

What’s your experience been? Are your DevOps efforts centered around a bridge-role model or embedded across your teams? Which path contributed most to sustainable operations at scale?

Let’s continue the conversation, and build DevOps systems that empower people first, tools second.

Coming up next:

Agentic SecDevOps, is it for you?

La pérennité est la nouvelle performance

Nous parlons sans cesse de performance :

• Vitesse
• Scalabilité
• Productivité

Ces questions restent cruciales. Pourtant, à l’heure où l’IA engloutit toujours plus d’énergie, où les écosystèmes s’épuisent et où la croissance économique exerce une pression croissante sur les limites planétaires et humaines, une interrogation plus profonde s’impose :

Est-ce durable ?

---

L’illusion d’une croissance infinie

Tout ce temps, la croissance a été l’étalon-or : plus d’utilisateurs, plus de calcul, plus de fonctionnalités, plus de revenus.
Mais « plus » ne rime pas toujours avec « mieux ». La croissance à tout prix cache souvent des coûts :

• dégradation environnementale ;
• épuisement professionnel ;
• inégalités ;
• dette technique ;
• fragilité opérationnelle.

Dans le secteur technologique, nous idolâtrons la vitesse : nous célébrons la disruption et poursuivons l’hyper-croissance. Or, des systèmes conçus uniquement pour aller vite finissent par casser – ou pire : ils nous lâchent au moment critique, tout en brûlant nos ressources et nos équipes.

---

Faire de la pérennité une exigence de premier plan

La pérennité n’est ni un supplément facultatif ni un « nice to have ».
C’est un critère de première classe, au même titre que la disponibilité, la latence ou le débit.

Quand nous demandons : « Est-ce durable ? », nous ne parlons pas seulement de :

• neutralité carbone ;
• efficacité énergétique ;
• impact écologique.

Nous voulons aussi savoir si :

• le système résiste au changement sans s’effondrer ;
• les personnes qui le font tourner peuvent s’épanouir, pas juste survivre ;
• la maintenance reste possible sans héroïsme sur le long terme ;
• on peut faire confiance au système, l’observer, l’expliquer et le gouverner.

---

Concevoir pour l’endurance, pas seulement la vitesse

Un leadership technologique durable implique :

• Des architectures durables : observables, modulaires, explicables et conscientes des limites du monde réel.
• Une automatisation intentionnelle : réduire la charge cognitive plutôt que camoufler la complexité.
• Une gouvernance intégrée : non parce que la conformité l’exige, mais parce que la confiance est la monnaie des systèmes modernes.
• Le souci des équipes : des processus et attentes qui préservent la santé mentale et renforcent la résilience.

La pérennité n’est pas une contrainte : c’est un prisme qui révèle où nous allons trop vite, où nous avons sauté les fondamentaux et où nous amplifions le gaspillage au lieu de la valeur.

---

Que signifie vraiment la croissance ?

• Si votre infrastructure consomme plus d’énergie qu’elle n’en crée de valeur…
• Si vos modèles d’IA demeurent opaques et incontrôlables…
• Si vos chaînes de livraison génèrent stress, retouches et systèmes "fantômes"…

Est-ce vraiment de la croissance ? Ou simplement du bruit à grande échelle ?

Nous avons besoin d’un nouveau référentiel de performance, intégrant endurance, clarté et responsabilité.

---

Vers une nouvelle définition de la valeur

Les systèmes les plus précieux du prochain quart de siècle ne seront pas seulement rapides.
Ils seront :

• fiables ;
• durables ;
• gouvernés ;
• observables ;
• humains.

Faisons de la pérennité plus qu’un mot à la mode : un principe de conception, un impératif commercial, une norme culturelle.
Car si votre système ne tient pas dans le temps, si votre croissance consume tout sur son passage, ce n’est pas aller de l’avant : c’est reculer.

---

Et si tout le reste était égal ?

Imaginez :

• Deux équipes obtiennent les mêmes résultats ;
• Deux stratégies atteignent les mêmes objectifs ;
• Deux systèmes délivrent la même performance.

Lequel choisirez-vous ?
Celui qui dure, qui consomme moins, soutient mieux les personnes et s’adapte sans rompre.

Pour les dirigeants, décideurs ou consultants, la pérennité n’est plus un créneau : c’est un multiplicateur de valeur et un avantage concurrentiel. C’est cela, un leadership responsable.

---

Parlons pérennité

Ces idées résonnent avec votre vision de la technologie, de la gouvernance ou du leadership ? Nous gagnerions à échanger. Ensemble, concevons des systèmes dignes d’être légués.

---

Ce qui a changé ?

• Des tournures plus idiomatiques et un rythme mieux adapté au français.
• Une cohérence terminologique : « pérennité » plutôt que variantes.
• Listing clair (•) et titres explicites pour faciliter la lecture sur écran.
• Allègement de certaines phrases trop proches de l’anglais (ex. « nice to have », « scale »).
• Suppression des points de suspension superflus et reformulation d’expressions familières pour un ton professionnel.

N’hésite pas si tu souhaites d’autres ajustements !

LLM ≈ calculatrices de poche, pour la tête.

Pourquoi la vraie question est de savoir comment nous les utilisons, et non si nous devrions les utiliser

« Je n'ai pas d'informations dans mon esprit qui sont facilement disponibles dans les livres... La valeur d'une éducation collégiale n'est pas l'apprentissage de nombreux faits, mais l'entraînement de l'esprit à penser.» — Albert Einstein (Citation Investigator)

1 · Pourquoi c'est important pour moi

J'ai passé trois décennies à mettre la technologie au service des gens, et non l'inverse. Les modèles en langage large (LLM) se trouvent maintenant sur mon établi à côté de Docker, Bicep et Git, mais seulement comme outils :

• Caisse de résonance – Je rédige des idées, je laisse le modèle remettre en question la clarté, puis je révise.
• Correcteur orthographique turbo – la grammaire, le ton, l'inclusivité et les nuances bilingues font l'objet d'un nettoyage rapide et respectueux.
• Pattern spotter – lorsque les journaux, le YAML ou les documents de politique s'étendent, un LLM aide à faire apparaître les valeurs aberrantes que je pourrais manquer.

2 · L'histoire se ressemble

Technologie	Peur initiale	Ce qui s'est réellement passé
Calculatrices de poche (salles de classe des années 1980)	« Les élèves oublieront comment ajouter. » Les syndicats d'enseignants ont protesté dans tout le pays. (easy-task.ai)	Les compétences en arithmétique mentale ont changé, mais les programmes de mathématiques ont progressé dans la chaîne de valeur (algèbre plus tôt, statistiques plus tôt).
Internet et Google (années 2000)	« Les moteurs de recherche nous rendent stupides. » (L'Atlantique, 2008) (L'Atlantique)	La littératie informationnelle est devenue vitale; la recherche a raffiné nos questions, pas notre capacité à raisonner.
LLM (aujourd'hui)	« L'IA remplacera les écrivains, les codeurs et les penseurs. »	Il fait pour le travail de connaissance ce que les calculatrices ont fait pour l'arithmétique, c'est-à-dire éliminer la corvée pour que nous puissions nous concentrer sur la perspicacité.

La tendance est claire : de nouveaux outils redistribuent la charge cognitive. Ils n'effacent pas nos capacités; ils élèvent là où nous les investissons. Alors bien sûr, je vais utiliser cet outil... lourdement.

3 · Les LLM dans une optique centrée sur l'humain

• Augmentez, n'abdiquez pas
• Je demande à un LLM de critiquer un manuel d'intervention en cas d'incident, puis je décide des améliorations qui correspondent à notre profil de risque.
• Traçabilité dès la conception
• Chaque changement assisté par l'IA est engagé avec la provenance dans Git. Les humains révisent avant de fusionner – pas de remplacements silencieux.
• Garde-fous en matière de protection de la vie privée et d'éthique
• Aucune donnée sensible des clients n'entre jamais dans un modèle public. Je maintiens des instances conteneurisées pour des contextes sécurisés.
• Boucle d'apprentissage continu
• Tout comme les exercices d'arithmétique mentale sont toujours importants, nous organisons des sprints « manuels seulement » : les équipes résolvent des tickets sans IA, puis comparons les résultats pour garder les compétences affûtées.

4 · Pourquoi les peurs persistent et comment y répondre

Préoccupation	Réfutation pratique
« Les gens arrêteront de penser. »	Outils de bande passante libre pourd'ordre supérieurla pensée – exactement le point de vue d'Einstein. (Citer l'enquêteur)
« Les résultats ne sont pas fiables. »	Traitez les brouillons LLM comme du code brut d'un développeur junior - révisez, testez, validez.
« Les emplois vont disparaître. »	Les rôles évoluent : l'ingénierie rapide, la gouvernance de l'IA et l'assurance qualité humaine sont déjà de nouveaux cheminements de carrière.

5 · Principes directeurs que j'observe. Que je suis.

• L'humanisme d'abord – L'empathie et le raisonnement critique restent irremplaçables.
• Transparence – Divulguer l'aide de l'IA dans les livrables.
• Responsabilité – L'auteur (moi) signe; le modèle n'a jamais le dernier mot.
• Durabilité – Préférez des modèles efficaces sur les appareils lorsque cela est possible pour réduire l'empreinte énergétique.
• Accessibilité – Utilisez l'IA pour abaisser les obstacles pour les collègues non techniques.

6 · Appel à l'action

La prochaine fois que vous verrez une suggestion de LLM apparaître, souvenez-vous de la calculatrice dans le tiroir de votre bureau : elle ne vous a pas fait oublier 2 + 2; elle vous a permis de résoudre x plus tôt. Manœuvrons l'IA avec la même intention : mieux penser ensemble.

#HumanisticAutomation #LLM #AIethics #ContinuousLearning #DevOps #TechForGood

 *Rédigé en collaboration avec ChatGPT 3o

LLMs ≈ Pocket Calculators for the Mind

Why the real question is how we use them, not if we should

“I don’t carry information in my mind that is readily available in books… The value of a college education is not the learning of many facts but the training of the mind to think.” — Albert Einstein (Quote Investigator)

 

1 · Why this matters to me

I’ve spent three decades putting technology at the service of people, not the other way around. Large-language models (LLMs) now sit on my workbench beside Docker, Bicep and Git—but only as tools:

• Sounding board – I draft ideas, let the model challenge clarity, then revise.
• Turbo spell-checker – grammar, tone, inclusiveness, and bilingual nuances get a quick, respectful scrub.
• Pattern spotter – when logs, YAML, or policy docs sprawl, an LLM helps surface the outliers I might miss.

2 · History keeps rhyming

Technology	Initial Fear	What Actually Happened
Pocket calculators (1980s classrooms)	“Students will forget how to add.” Teachers’ unions protested nationwide. (easy-task.ai)	Mental arithmetic skills shifted, but math curricula moved up the value chain (algebra sooner, statistics earlier).
The Internet & Google (2000s)	“Search engines are making us stupid.” (The Atlantic, 2008) (The Atlantic)	Information literacy became vital; search refined our questions, not our ability to reason.
LLMs (today)	“AI will replace writers, coders, thinkers.”	It’s doing for knowledge work what calculators did for arithmetic—removing drudgery so we can concentrate on insight.

The pattern is clear: new tools redistribute cognitive load. They do not erase our abilities; they elevate where we invest them. So of course I'm going to use this tool. Heavily.

3 · LLMs through a human-centric lens

• Augment, don’t abdicate

  • I ask an LLM to critique an incident-response playbook, then I decide which refinements fit our risk profile.

• Traceability by design

  • Every AI-assisted change is committed with provenance in Git. Humans review before merge—no silent overrides.

• Privacy & ethics guardrails

  • No sensitive client data ever enters a public model. I maintain air-gapped, containerized instances for secure contexts.

• Continuous learning loop

  • Just as mental arithmetic drills still matter, we run “manual-only” sprints: teams solve tickets without AI, then compare outcomes to keep skills sharp.

4 · Why fears persist—and how to answer them

Concern	Practical Rebuttal
“People will stop thinking.”	Tools free bandwidth for higher-order thinking—exactly Einstein’s point. (Quote Investigator)
“Outputs are unreliable.”	Treat LLM drafts like raw code from a junior dev—review, test, validate.
“Jobs will vanish.”	Roles evolve: prompt engineering, AI governance, and human-in-the-loop QA are already new career paths.

5 · Guiding principles I follow

• Humanism first – Empathy and critical reasoning remain irreplaceable.
• Transparency – Disclose AI assistance in deliverables.
• Accountability – The author (me) signs off; the model never owns the final word.
• Sustainability – Prefer efficient, on-device models when possible to reduce energy footprint.
• Accessibility – Use AI to lower—not raise—the barrier for non-technical colleagues.

6 · Call to Action

Next time you see an LLM suggestion pop up, remember the calculator in your desk drawer: it didn’t make you forget 2 + 2; it let you solve for x sooner. Let’s wield AI with the same intent—to think better together.

*Written in collaboration with ChatGPT 3o

#HumanisticAutomation #LLM #AIethics #ContinuousLearning #DevOps #TechForGood

Sustainability Is the New Performance

We talk a lot about performance — in business, in systems, in teams.

How fast?
How scalable?
How productive?

These are important questions, but in this age — where AI consumes ever-growing energy, where our ecological systems are in crisis, and where relentless economic growth strains planetary and human limits — we need to start asking a deeper, more consequential question:

Is it sustainable?

 

---

The Illusion of Infinite Growth

For decades, growth has been treated as the gold standard: the only meaningful metric of success.
More users. More compute. More features. More revenue.

But more does not always mean better. And growth at all costs often comes with a hidden price tag: environmental degradation, burnout, inequality, technical debt, and fragility.

In technology, we idolize velocity.
We celebrate disruption.
We chase scale.

But systems that are optimized only for speed are systems that eventually fail, or worse, fail us. They burn resources, burn out people, and leave behind operational chaos.

---

Sustainability as a First-Class Metric

It’s time we shift the conversation.
Sustainability is not an afterthought.
It’s not a “nice to have.”
It’s a first-class requirement, every bit as essential as uptime, latency, or throughput.

When we ask “Is it sustainable?”, we don’t just mean:

• Is it green?
• Is it carbon-neutral?
• Is it efficient?

We mean:

• Can this system adapt to change without collapsing?
• Can the people running it thrive, not just survive?
• Can we maintain it responsibly, over time, without heroics?
• Can it be trusted, observed, explained, and governed?

---

Designing for Endurance, Not Just Velocity

Sustainable tech leadership means:

• Building systems that last: observable, modular, explainable, and respectful of real-world limits.
• Automating with intent: using automation to reduce cognitive load, not to mask complexity.
• Embedding governance: not because compliance requires it, but because trust is the currency of modern systems.
• Caring for our teams: designing processes and expectations that protect mental health and build resilience.

Sustainability isn’t a limit. It’s a lens.

It reveals where we’re going too fast.
Where we’ve skipped the fundamentals.
Where we’re scaling waste instead of value.

---

What Does Growth Really Mean?

If your infrastructure burns more energy than it returns in value…
If your AI model can’t be explained or constrained…
If your delivery pipeline causes stress, rework, and shadow systems…

Is that really growth?
Or is it just noise at scale? "Oh look at me, I'm a big, something."

We need a new kind of performance metric, one that includes endurance, clarity, and responsibility.

---

A New Definition of Value

The most valuable systems in the next part of this century won’t just be fast.
They’ll be trusted.
They’ll be sustainable.
They’ll be governed, observable, and humane.

Let’s make sustainability more than a buzzword
Let’s make it a design principle, a business imperative, and a cultural norm.

Because if your system can’t last…
If your growth burns everything behind it…

That’s not forward.
That’s backwards.

A propos de

Jean-Paul Lizotte (« Jaypee »)

Responsable de la transformation SecDevOps | Confiance zéro et automatisation de la conformité | 30+ ans dans les TI pour une prestation résiliente et centrée sur les personnes

Je crée des cultures d’ingénierie Zero-Trust à haute confiance. De la programmation de Microsoft BASIC en 1981 à la direction d’attestations SOC 2 de type II, ma carrière s’articule autour d’une idée : la technologie doit responsabiliser les gens, et non devenir leur goulot d’étranglement

Aujourd’hui, j’accompagne les organisations hors de la « dépendance au gourou » et vers des écosystèmes SecDevOps collaboratifs et auto-réparateurs qui réduisent les délais, améliorent la posture de sécurité et rendent les audits presque invisibles pour les ingénieurs .

Résultats de signature

• SOC 2 Préparation de type II en moins de 12 mois – Automatisation et coordination de la mise en œuvre des contrôles de vérification.
• 45% moins de défauts de production après l’intégration des portes SAST / DAST / IaC dans CI / CD.
• Livraisons quotidiennes au lieu des trois semaines en entraînant cinq équipes interfonctionnelles sur le développement basé sur le tronc et les "feature-flags".
• Zone d’atterrissage Azure en étoile Bicep Deployment, avec une politique en tant que code et des points de terminaison privés, hébergeant désormais 30 + charges de travail. 

Mon guide ("playbook")

1. Stratégie et gouvernance – Associez les risques d'affaires aux garde-fous; intégrez la conformité dans le flux de travail.
2. Automatisation – Tout en tant que code : pipelines, politiques, infrastructure.
3. Culture – Sécurité psychologique, imputabilité partagée, boucles de rétroaction continues, sécurité dans tout.

Compétences de base

• Leadership et transformation culturelle de SecDevOps
• Architecture Zero Trust et conformité SOC 2 Type II
• CI / CD & IaC : Azure DevOps · GitHub Actions · Bicep · Docker / AKS
• Gouvernance multi-cloud et hybride (Azure-first, un peu de AWS)
• Sécurité des données et des pipelines : SAST · DAST · Gestion des secrets · Centralisation des journaux SIEM, SonarQube, Snyk
• Coaching et mentorat d’équipes interfonctionnelles

Rôles récents

Émyode | Certifié B Corp

7 ans 10 mois

Responsable de la pratique SecDevOps | CIOSO adjoint

Mai 2024 - Mai 2025 (1 an 1 mois)
Montréal, Québec, Canada

En tant qu’adjoint du CIOSO, j’ai contribué à la stratégie de sécurité opérationnelle de l’entreprise en identifiant les risques systémiques, en établissant des contrôles de processus et en mettant en œuvre des cadres de gouvernance évolutifs dans les équipes de développement. Un élément clé de ce rôle consistait à diriger la mise en œuvre du programme de préparation à la sécurité SOC 2 d’Emyode, en alignant les équipes et les opérations sur des contrôles d’audit rigoureux et des normes de conformité fondées sur des données probantes. En tant que chef de pratique SecDevOps, j’ai favorisé une culture axée sur la sécurité en intégrant la sécurité à chaque étape du SDLC. J’ai encadré des équipes interfonctionnelles sur l’automatisation sécurisée, la modélisation des menaces et l’amélioration continue, transformant la maturité DevOps en valeur commerciale mesurable. 

Principales contributions : 

• Mise en œuvre de l’initiative de préparation SOC 2, de l’analyse des lacunes à la mise en œuvre des politiques et à la collecte d’éléments probants, en veillant à ce que l’état de préparation de la vérification soit disponible.
• Conception de pipelines DevSecOps avec des contrôles de qualité et de conformité intégrés.
• A dirigé des formations sur la sécurité, des ateliers sur les risques et des revues d’architecture avec des équipes internes et des clients externes.
• Des mesures et des tableaux de bord établis pour les indicateurs clés de performance de sécurité en temps réel et le suivi des mesures correctives.
• Agent de liaison pour soutenir la communication entre les intervenants et les équipes de sécurité. Pilotage du programme SOC 2 de l’entreprise, mise en place de contrôles Zero-Trust et observabilité centralisée