Augmenter nos pipelines SecDevOps sur Azure avec des agents IA (2/2)

Ce que nous augmentons (en termes simples)

Nous travaillons avec Azure DevOps et Azure Cloud depuis assez longtemps pour connaître cette vérité: nos pipelines produisent déjà les données/réponses dont nous avons besoin, mais ils les cachent dans des journaux, des métriques et des alertes répartis dans les outils. Les agents de l’IA nous aident à assembler cette histoire. Dans cet article, nous partageons un modèle simple et concret que nous utilisons chez JPSoftWorks pour augmenter SecDevOps sur Azure avec des agents qui surveillent, corrèlent et conseillent, sans gêner l’équipe.

Où l’agent se branche

Notre base de référence nous semble familière : Azure Repos ou GitHub, Azure Pipelines pour CI/CD, portes de sécurité pour SCA/SAST/DAST et déploiements d’atterrissage dans Azure Kubernetes Service (AKS) ou Azure App Service. L’observabilité réside dans Azure Monitor et Application Insights, Defender pour le cloud et Microsoft Defender pour DevOps alimentant les signaux de risque. Cette pile est solide, mais les gens se noient toujours dans l’information. La couche d’agent renverse le scénario en faisant trois choses pour nous:

1. Enrichir : Capturez les sorties du pipeline, les journaux et les résultats de sécurité; ajoutez du contexte comme les validations récentes, les différences de dépendance, la dérive de l’infrastructure et les tickets de modification.
2. Corréler : Relier les symptômes aux causes probables. Par exemple, associez un pic de temps de déploiement à un crochet Helm nouvellement ajouté, ou associez une augmentation des vulnérabilités faussement positives à une mise à jour de la règle d’analyse.
3. Conseiller : Proposer des actions qui s’adaptent à nos garde-fous. Il peut s’agir d’ouvrir automatiquement une PR pour resserrer une politique Azure, de suggérer un changement de parallélisme de test ou d’escalader un incident réel au bon canal d’équipe de service.

Nous plaçons l’agent d’IA sur le chemin d’événement qui existe déjà dans Azure :

• Ingestion : Azure Pipelines publie des artefacts et des journaux de build/test dans Azure Blob Storage; les données de télémétrie sont transmises à Log Analytics via Azure Monitor et Application Insights. Les signaux de sécurité arrivent de Defender pour le Cloud et de Defender pour DevOps.
• Bus : Nous reflétons les événements clés dans Event Hubs (ou Service Bus) pour garder l’agent découplé du pipeline (important).
• Runtime de l’agent : un service léger sur Azure Functions ou un conteneur dans AKS s’abonne à ces événements.
• Raisonnement + politiques : L’agent utilise nos invites (prompts), règles et playbooks internes, et lorsque nous avons besoin de capacités LLM, nous appelons Azure OpenAI avec un ancrage strict sur notre propre base de connaissances dans Azure AI Search ou un compte de stockage privé.
• Action : L’agent réécrit les commentaires dans Azure DevOps (fils de discussion PR, résumés de pipeline), crée des branches Git avec des correctifs, file des éléments de travail ADO ou publie des alertes annotées dans Teams. Pour les problèmes d’exécution, il peut ouvrir un incident Sentinel avec des preuves enrichies.

Ce que cela change pour l’observabilité

• Des journaux bruts aux récits : Au lieu de cinq alertes dans cinq outils, nous obtenons un récit : « Le déploiement a ralenti de 34% depuis le 20 août après l’ajout d’OWASP ZAP à l’étape de publication; envisagez de paralléliser les analyses ou de définir la portée des cibles.
• Sensibilisation aux tendances : L’agent suit les lignes de base mobiles. Lorsque le temps de construction augmente de 5% par semaine pendant trois semaines, nous en entendons parler avant de le sentir.
• Priorisation de la sécurité : Les résultats sont classés en fonction de l’exploitabilité, de l’exposition et du rayon d’explosion. Un chemin critique sur un code mort ne saute pas la file d’attente sur un support sur un service Internet.
• Boucles de rétroaction : L’agent teste ses propres conseils. Si la réduction de la conservation des journaux nuit aux médico-légaux, elle annule la recommandation et explique pourquoi.

Un plan simple dans Azure

Voici un diagramme minimal que nous utilisons pour expliquer le modèle aux équipes. (cliquez pour agrandir)

 

Comment nous l’exploitons en toute sécurité

• Les limites des données d’abord : l’agent ne voit que ce qu’il doit. Nous étendons les requêtes Log Analytics par service et nous acheminons les secrets via Key Vault. Les appels de LLM sont privés, et la consignation rapide et de réponse est effacée.
• Expliquez, puis agissez : les conseils sont par défaut; les actions nécessitent soit un runbook avec des types de changements préapprouvés, soit une approbation humaine explicite dans la vérification de la demande de tirage ou du pipeline.
• Connaissances versionnées : Les playbooks qui guident l’agent sont versionnés comme du code et validés dans des pipelines non producteurs.
• Contrôle des coûts : Nous regroupons les événements, utilisons la génération augmentée de récupération uniquement lorsque cela est nécessaire et mettons en cache le raisonnement préalable pour les problèmes répétés.

Cas d’utilisation du jour 1:

1. Détecteur de dérive de pipeline : Alertez lorsque l’ordre des étapes, les conditions ou les budgets de temps changent considérablement; ouvrez un PR pour rétablir les normes.
2. Réducteur de bruit pour les analyses de sécurité : regroupez les doublons, supprimez les familles connues et reclassez-les par chemins d’exposition découverts à partir d’Azure Resource Graph.
3. Chien de garde SLO : surveillez les budgets d’erreurs à partir d’App Insights; si le taux d’utilisation dépasse la politique, l’agent met en pause les déploiements risqués et propose un retour en arrière avec des liens vers des traces défaillantes.
4. Coach en risque de dépendance : Lorsqu’un nouveau colis atterrit, l’agent vérifie les fenêtres de support et les vulnérabilités transitives, puis propose une solution de rechange ou une stratégie d’épinglage plus sûre.

Conclusion : nous conservons notre pile Azure existante. Nous ajoutons simplement un agent qui écoute plus attentivement, relie les points plus rapidement et nous pousse à prendre de meilleures décisions.

Augmenting SecDevOps Pipelines with AI Agents on Azure (part 2/2)

 

What we’re augmenting (in plain terms)

We’ve been hands-on with Azure DevOps and Azure cloud long enough to know this truth: our pipelines already produce the answers we need, but they hide them in logs, metrics, and alerts spread across tools. AI agents help us stitch that story together. In this post we share a simple, concrete pattern we use at JPSoftWorks to augment SecDevOps on Azure with agents that watch, correlate, and advise—without getting in the team’s way.

Where the agent plugs in

Our baseline looks familiar: Azure Repos or GitHub, Azure Pipelines for CI/CD, security gates for SCA/SAST/DAST, and deploys landing in Azure Kubernetes Service (AKS) or Azure App Service. Observability lives in Azure Monitor and Application Insights, with Defender for Cloud and Microsoft Defender for DevOps feeding risk signals. That stack is solid, but people still drown in information. The agent layer flips the script by doing three things for us:

1. Enrich: Capture pipeline outputs, logs, and security findings; add context like recent commits, dependency diffs, infra drift, and change tickets.
2. Correlate: Link symptoms to likely causes. For example, tie a spike in time-to-deploy to a newly added Helm hook, or associate a rise in false-positive vulns with a scanner rule update.
3. Advise: Propose actions that fit our guardrails. That might be auto-opening a PR to tighten an Azure Policy, suggesting a change in test parallelism, or escalating a real incident to the right service team channel.

We place the AI agent on the event path that already exists in Azure:

• Ingest: Azure Pipelines publishes build/test artifacts and logs to Azure Blob Storage; telemetry flows into Log Analytics via Azure Monitor and Application Insights. Security signals arrive from Defender for Cloud and Defender for DevOps.
• Bus: We mirror key events to Event Hubs (or Service Bus) to keep the agent decoupled from the pipeline.
• Agent runtime: A lightweight service on Azure Functions or a container in AKS subscribes to those events.
• Reasoning + policies: The agent uses our in-house prompts, rules, and playbooks, and when we need LLM capabilities we call Azure OpenAI with strict grounding against our own knowledge base in Azure AI Search or a private storage account.
• Action: The agent writes comments back to Azure DevOps (PR threads, pipeline summaries), creates Git branches with fixes, files ADO work items, or posts annotated alerts to Teams. For runtime issues it can open a Sentinel incident with enriched evidence.

What it changes for observability

• From raw logs to narratives: Instead of five alerts in five tools, we get one narrative: “Deployment slowed by 34% since Aug 20 after adding OWASP ZAP to release stage; consider parallelizing scans or scoping targets.”
• Trend awareness: The agent tracks moving baselines. When build time creeps 5% weekly for three weeks, we hear about it before we feel it.
• Security prioritization: Findings get ranked by exploitability, exposure, and blast radius. A critical on a dead code path doesn’t jump the queue over a medium on an internet-facing service.
• Feedback loops: The agent tests its own advice. If shortening log retention hurts forensics, it rolls back the recommendation and explains why.

A simple Azure blueprint

Here’s a minimal diagram we use to explain the pattern to teams. (click to expand)

How we run it safely

• Data boundaries first: The agent only sees what it must. We scope Log Analytics queries per service, and we route secrets through Key Vault. LLM calls are private, with prompt/response logging scrubbed.
• Explain, then act: Advice is default; actions require either a runbook with pre-approved change types or explicit human approval in the PR or pipeline check.
• Versioned knowledge: The playbooks that guide the agent are versioned like code and validated in non-prod pipelines.
• Cost controls: We batch events, use Retrieval-Augmented Generation only when needed, and cache prior reasoning for repeated issues.

Day-one use cases

1. Pipeline drift detector: Alert when stage order, conditions, or time budgets change materially; open a PR to restore standards.
2. Noise reducer for security scans: Group duplicates, suppress known-benign families, and re-rank by exposure paths discovered from Azure Resource Graph.
3. SLO watchdog: Watch error budgets from App Insights; if burn rate exceeds policy, the agent pauses risky deploys and proposes a rollback with links to failing traces.
4. Dependency risk coach: When a new package lands, the agent checks support windows and transitive vulns, then proposes a safer alternative or pin strategy.

Bottom line: we keep our existing Azure stack. We just add an agent that listens harder, connects dots faster, and nudges us toward better decisions.

Augmenter nos pipelines SecDevOps avec des agents IA (1/2)

 

Pourquoi l’IA a naturellement sa place dans le SecDevOps

Si vous nous connaissez, vous savez que nous avons toujours pensé que le SecDevOps repose sur un équilibre: sécurité, développement et opérations doivent avancer ensemble, sans ralentir la livraison, tout en restant solides et sécurisés. Aujourd’hui, avec l’arrivée des agents IA, nous voyons une nouvelle occasion d’aller plus loin. L’IA peut nous aider à observer, interpréter et même anticiper ce qui se passe dans nos pipelines. Cela signifie plus de contexte pour les équipes, une réponse plus rapide aux changements, et une meilleure utilisation des données déjà produites.

Nos pipelines génèrent déjà une masse d’informations : journaux de build, résultats de tests, vérifications de dépendances, scans de vulnérabilités, métriques de déploiement, données de monitoring. Les humains savent reconnaître des schémas, mais pas à la vitesse et à l’échelle nécessaires. Les agents IA, eux, sont conçus pour extraire les signaux pertinents de ce bruit. En les intégrant dans nos pratiques, nous ajoutons un observateur qui voit tout, qui se souvient des tendances passées et qui s’adapte aux nouveaux risques.

L’objectif n’est pas de remplacer les ingénieurs ou analystes, mais de leur donner une vision plus claire pour agir plus vite et plus juste.

Une observabilité enrichie

L’observabilité reste un défi central dans le SecDevOps. Savoir qu’il y a une erreur ne suffit pas : il faut comprendre pourquoi. Les agents IA peuvent aider à :

• Détecter des anomalies dans les journaux et sorties que les règles d’alerte classiques manquent.
• Suivre des évolutions subtiles comme une lente dégradation des performances ou des pics de faux positifs.
• Offrir des explications contextuelles, reliant les problèmes à un changement de code, une mise à jour de dépendance ou un décalage d’infrastructure.

Les journaux deviennent alors une source vivante d’intelligence.

Anticiper les incidents

Les pipelines évoluent sans cesse : nouveaux outils, dépendances mises à jour, nouvelles pratiques de déploiement. Les agents IA peuvent surveiller ces changements et signaler quand ils introduisent des effets inattendus. Par exemple, si une bibliothèque mise à jour entraîne une augmentation des alertes de sécurité, ou si une nouvelle stratégie de déploiement complique les retours arrière, l’IA peut faire le lien rapidement.

C’est là que la dimension humaine prend toute son importance : grâce à de meilleures informations, les équipes passent moins de temps à éteindre des incendies et plus de temps à renforcer la qualité.

De la donnée à la décision

La vraie valeur ajoutée vient de la prise de décision :

• Prioriser les vulnérabilités avec du contexte, plutôt qu’une simple liste brute.
• Ajuster les pipelines avant que des petites inefficacités ne deviennent des goulets d’étranglement.
• Réagir aux incidents de sécurité avec plus de précision grâce à une analyse déjà pré-filtrée par l’IA.

Quand les équipes ont confiance dans les signaux de leurs pipelines, elles avancent plus vite et plus sereinement.

Notre vision

Chez JPSoftWorks, nous expérimentons l’intégration d’agents IA à des points clés de nos workflows SecDevOps. Pour nous, ce n’est pas une question de mode ou de jolis graphiques. C’est un moyen d’apporter plus de clarté aux développeurs, aux opérationnels et aux experts sécurité. Cela renforce autant la culture que la technologie : des équipes mieux soutenues collaborent mieux et innovent avec plus de confiance.

L’IA ne simplifie pas tout d’un coup. Mais elle rend le SecDevOps plus éclairé. Et des pipelines éclairés sont la base d’une livraison logicielle sécurisée et durable.

Restez avec nous pour la deuxième partie, demain, lorsque nous vous montrerons comment implémenter cette pratique. 

Augmenting SecDevOps Pipelines with AI Agents (1/2)

 

Why AI Fits Naturally into SecDevOps

As many of you know by now, we've always believed that SecDevOps is about balance: security, development, and operations working together in a way that doesn't slow delivery but still keeps everything secure and resilient. Now, with the rise of AI agents, we see new opportunities to push that balance even further. AI can help us observe, interpret, and even predict what's happening inside our pipelines. That means more context for teams, faster response to change, and smarter use of the data we already generate.

Our pipelines already generate a flood of signals: build logs, test results, dependency checks, vulnerability scans, deployment metrics, and runtime monitoring data. Humans are good at spotting patterns, but we can't keep pace with the sheer volume. AI agents excel at surfacing meaningful insights from this noise. By layering them into SecDevOps, we give ourselves an assistant that watches everything, remembers past trends, and adapts to evolving risks.

This isn't about replacing engineers or security analysts. It's about giving them a set of lenses to see more clearly, so they can act on the right information at the right time.

Observability with More Depth

One of the toughest challenges in SecDevOps is observability. We need to know not only whether something failed, but why. AI agents can augment this by:

• Detecting anomalies in logs and outputs that aren't obvious to standard alert rules.
• Tracking subtle changes in pipeline behavior over time, like increasing build durations or rising false positives in scans.
• Providing contextual explanations so teams can interpret issues in relation to code changes, dependency updates, or infrastructure drift.

Instead of treating logs as static output, we're able to turn them into living intelligence.

Spotting Trends Before They Become Incidents

Another powerful capability is trend detection. Pipelines evolve constantly: new tools get integrated, dependencies shift, developers try different practices. AI agents can monitor these changes and highlight when something introduces unexpected side effects. For example, if a library upgrade correlates with a spike in security scan alerts, or a new deployment pattern leads to slower rollback times, the AI can connect those dots faster than manual analysis.

This is where the human side of SecDevOps matters most. By providing better context, AI frees our teams from reactive firefighting and gives them space to make proactive improvements.

From Data to Decisions

The ultimate value of AI in our pipelines comes from how it shapes decision-making. With more accurate and timely observability, teams can:

• Prioritize vulnerabilities with real context instead of raw CVE lists.
• Adjust pipelines before small inefficiencies turn into bottlenecks.
• Respond to security incidents with more precision, since the AI agent has already narrowed down likely root causes.

We've seen that when engineers trust the signals coming from their pipelines, they spend less time second-guessing alerts and more time building secure features.

Our Path Forward

At JPSoftWorks, we're experimenting with embedding AI agents at key points in our SecDevOps workflows. For us, it's not about flashy dashboards or buzzwords. It's about giving developers, operators, and security professionals a clearer picture of what's happening, without drowning them in noise. We believe this approach strengthens culture as much as technology: when teams feel supported by their tools, they collaborate better and take smarter risks.

AI won't make SecDevOps easier overnight, but it will make it more informed. And informed pipelines are the foundation of secure, resilient software delivery.

Join us tomorrow for part two, how to implement such a process in your existing pipelines.

Vibe Coding: Are Humans an asset or a threat?

As usual, our people are our salvation

We’ve seen cybersecurity evolve: from basement script kiddies to AI-fueled threats. And yet as we enter late 2025, Alan Shimel’s article “Distraction is the New Zero‑Day: The Human Risk We Keep Ignoring” rings truer than ever. It’s not ransomware or deepfake scams causing the most damage: it’s good old distraction. According to KnowBe4 research, 43 % of breaches are traced back to employee distraction, outpacing training gaps (41 %), pressure to act fast (33 %), fatigue (31 %), and even the sophistication of the threats (17.1 %) (Security Boulevard).

That’s a stark reminder: no matter how advanced your tech, if people are juggling too much, security unravels.

Enter vibe coding: how some teams will distinguish themselves. It’s not just a buzzword. It’s code being co‑authored by AI copilots like Microsoft Copilot, Claude, or ChatGPT. This new paradigm has arrived, and it's not just changing how we write code: it’s shaking up how security must be woven in. After all, we aren't there to slow you down in your endeavors.

Our processes are our weapons.

Here’s how we bridge that gap:

• Humans stay in control. AI is a tool, not an operator. It can craft and suggest: but accountability remains decidedly human.
• Security belongs in the flow. AI accelerates development: but without thoughtful guardrails, it opens doors for blind spots. We bake in safe defaults, code reviews, prompts that call out risky patterns.
• Awareness is the ultimate defense. In a distracted, hyper‑speed environment where AI suggestions flood the screen, our attention becomes the firewall. As Shimel cautions, distraction is the real zero‑day. Let’s guard against that, not just bug fixes.

At JPSoftWorks, we don’t just welcome vibe coding: we help organizations use it wisely. Because in a world where AI supports coding, the strongest security asset remains human intuition: if given the space, context, and tools to do its thing.

L'humain dans le "vibe coding": Un atout ou un risque additionnel?

L'les personnes à la rescousse

Nous avons vus la cybersécurité évoluer: from des pirates amateurs aux menaces IA. Mais fin 2025, l’article d’Alan Shimel "Distraction is the New Zero‑Day : The Human Risk We Keep Ignoring" résonne clairement. Ce ne sont ni les ransomwares ni les deepfakes qui causent le plus de dégâts: c’est la distraction. D’après une étude KnowBe4, 43 % des incidents sont liés à la distraction des employés, quand le manque de formation atteint 41%, la pression 33%, l’épuisement 31%, et la sophistication des attaques seulement 17,1% (Security Boulevard, IT Pro).

Un signal fort: peu importe la robustesse de vos technologies, si les gens sont surchargés, la sécurité se fissure.

Voici comment nous abordons cela via le vibe coding, version 2025 chez JPSoftWorks: Ce n’est pas un simple terme tendance. C’est du code co-réalisé avec des copilotes IA comme Microsoft Copilot, Claude ou ChatGPT. Une nouvelle ère du développement est là, et elle impose de repenser la sécurité. Après tout on est pas là pour tenter de freiner vos élans.

Les processus sont nos défenses.

Notre approche :

• L’humain garde la main. L’IA est un outil, pas un décideur. Elle peut suggérer ou rédiger: mais la responsabilité reste humaine.
• La sécurité fait partie du flux. L’IA accélère l’écriture, mais sans garde-fous, elle laisse des angles morts. On intègre des prompts sûrs, des revues de sécurité, des configurations défensives.
• La conscience humaine est la vraie protection. Dans un monde où la distraction nous guette et les suggestions IA pullulent, notre attention devient le pare-feu. Comme Shimel l’alerte, la distraction est la faille zéro. Préservons-la, pas seulement les patchs.

Chez JPSoftWorks, on ne se contente pas d’adopter le vibe coding: on aide les équipes à l’utiliser correctement. Parce que dans un monde où l’IA assiste le code, l’atout sécurité le plus solide reste l’intuition humaine: à condition qu’on lui donne l’espace, le contexte et les outils.

L’excellence en ingénierie est-elle une espèce en voie de disparition?

Une réflexion SecDevOps sur le rapport 2025 "State of Software Engineering Excellence"

---

Pourquoi ce rapport est important pour moi

Si vous suivez mes périples écrits, vous savez que je considère DevOps (et son aîné SecDevOps) comme un sport d'équipe: trouver l'équilibre entre vitesse et sécurité, humanité et processus, durabilité et valeur pour les actionnaires. Lorsque Harness a publié la semaine dernière son étude State of Software Engineering Excellence 2025, j'ai pris un café et dévoré les plus de 30 pages du rapport.

Le constat est brutal: la majorité des organisations n'atteignent toujours pas la cible en matière d'expérience développeur et de maturité DevOps, ce qui se traduit par une productivité en baisse, un risque qui s'envole et des talents frustrés. (harness.io)

---

Aperçu des constats

Point problématique	Données du sondage
Boucles de rétroaction lentes	67 % des équipes n'arrivent pas à mettre en place un environnement complet de build/test en 15 minutes
Tâches manuelles	64 % déploient encore le code infra à la main ; 50 % livrent les applis manuellement
Temps d'attente pour revue de code	61 % attendent plus d'une journée pour une revue
Absence de garde-fous qualité	55 % des pipelines CI/CD n'ont aucun contrôle de passage
Lacunes dans la préparation aux incidents	52 % manquent d'outils clés pour la réponse aux incidents
Angles morts en sécurité	38 % ne scannent pas leurs builds ; 1 équipe sur 10 laisse passer des bogues critiques en prod ; médiane de correction ≥ 7 jours pour les vulnérabilités graves

Ajoutez à cela:

• Seulement 29 % disposent d'un catalogue logiciel à jour.
• À peine 19 % offrent un programme structuré de montée en compétences aux devs.
• Un quart des équipes admet que plus de 70 % des user stories n'ont pas de critères d'acceptation clairs.

Pour le dire bêtement, le moteur DevOps cogne, le témoin moteur clignote et on roule encore à 120 km/h sur la 132.

---

Pourquoi cet écart persiste-t-il?

Dans mes mandats de conseil, je vois trois antipat­terns récurrents:

1. Un DevOps centré sur le rôle: on embauche un"magicien du pipeline"et on espère que la magie se répande.
2. L'obsession"tool-first": on achète les meilleurs gadgets sans toucher aux processus ni à la dynamique d'équipe.
3. Le culte de la vélocité à court terme: on livre des fonctionnalités plus vite aujourd'hui en accumulant la dette technique (et les blessures de stress) pour demain.

Les données Harness confirment les trois: beaucoup d'outils tape-à-l'œil, mais des contrôles manuels ; quelques poches d'excellence, mais zéro ownership transversal ; des ingénieurs héroïques, mais des systèmes fragiles.

---

Les avantages de la trajectoire actuelle (oui, il y en a)

Ce qui fonctionne	Pourquoi c'est quand même positif
La prise de conscience progresse	650 leaders ont pris le temps de s'auto-évaluer: c'est déjà un pas culturel.
La pensée plateforme émerge	Le rapport fait la promotion des plateformes de livraison logicielle unifiées, exactement ce que prône le SecDevOps moderne.
La formation sécurité existe	56 %* forment au moins annuellement leurs devs. Pas parfait, mais c'est une base. (harness.io)
Les métriques supplantent les anecdotes	L'usage d'une grille de maturité fait passer la discussion du "ressenti" à la preuve.

*Note verre à "moitié plein": cela signifie aussi que 44 % forment moins d'une fois par an, voire jamais.

---

Les inconvénients (le vrai centre de coûts)

• Hémorragie de productivité: chaque pause de 30 minutes en attente d'une revue, c'est des intérêts composés de gaspillage.
• Dette de sécurité: une semaine pour patcher une vulnérabilité critique, c'est l'éternité pour un attaquant ; les exploits de chaîne d'approvisionnement n'attendent pas le sprint planning.
• Épuisement des personnes: déploiements manuels et incidents hors heures font naître la fatigue que l'IA promettait d'éliminer.
• Frein à l'innovation: des talents occupés à réparer des pipelines cassés ne créent pas la prochaine fonctionnalité.

Multipliez cela par les salaires mondiaux et vous comprenez les "millions" cités par Harness. (harness.io)

---

Un prisme SecDevOps sur les recommandations

Sans surprise, Harness prône une approche centrée plateforme. Je suis d'accord… avec réserves.

Prescription Harness	Ma bonification SecDevOps
Automatiser les pipelines de bout en bout	Oui, mais le policy-as-code doit verrouiller chaque étape: SAST, SBOM, dérive IaC, scan de secrets, Snyk, SonarQube, & Cie.
Adopter des portails développeur internes (IDP)	Absolument, mais avec des paramètres de moindre privilège par défaut et des garde-fous pour éviter l'infra "clandestin".
Former en continu	Incontournable. Combinez les sessions de code sécuritaire obligatoires à une rotation en gestion d'incident pour développer l'empathie.
Mesurer la maturité sur cinq axes	Faites-le, mais complétez la grille par les métriques DORA pour garder le duo débit, fiabilité et un prisme SevDevOps je vous prie. (wikipedia.org)

---

Le changement culturel prime sur le changement de plateforme

On ne peut pas sécuriser ce qu'on ne comprend pas; on ne peut pas automatiser ce qu'on n'a pas convenu de standardiser. Cela exige:

• Rétrospectives sans blâme et sans filtre: mettre en lumière les frictions derrière ces builds de moins de 15 minutes.
• SLO partagés: dev, ops et sécurité portent la même imputabilité, "MTTR" et taux d'échec de déploiement.
• KPI de durabilité: suivre la charge d'astreinte, les plages hors heures et les heures de formation comme des métriques de première classe. (Voir la recherche émergente sur le Sustainable DevOps: arxiv.org et notre article La pérennité est la nouvelle performance)

---

L'aspect humain : la variable manquante

Le rapport traite de dollars et de défauts. Ajoutons la dimension humaine :

• Travail manuel = épuisement.
• Attente de revue = désengagement.
• Incidents lents = on réveille le même héros à 3 h du matin.

S'attaquer à ces points n'est pas qu'une stratégie de rétention: c'est de la gestion des risques. Un esprit fatigué configure mal, la prod!

---

Mon plan d'action en quatre points

1. Cartographier le gaspillage. Time-in-queue, et non les lignes de code, est mon indicateur phare. Si vos PR stagnent plus de 12 heures, réparez la boucle de feedback avant d'acheter un autre scanner.
2. Déplacer les conversations sécurité à gauche. Les outils détectent des motifs ; les humains jugent la plausibilité. Organisez des"brown-bags"de modélisation des menaces pour que les devs flairent le danger avant la PR.
3. Investir autant dans la plateforme que dans les personnes. Un IDP robuste sans plan de rotation finit sur l'étagère. Associez chaque nouveau service self-service à un module de compétences et un check-in sur la sécurité psychologique.
4. Faire un audit de maturité. Vous ignorez par où ou par qui commencer? Contactez-nous. Mais pour arriver quelque part, il faut savoir d'où vous partez.

---

L'IA: sa place (et ses limites)

Les agents façon Copilot peuvent proposer des configs sécurisées et générer des tests automatiquement. Mais ils ne peuvent pas:

• Négocier les critères d'acceptation avec les parties prenantes.
• Décider de l'appétence au risque de votre organisation.
• Mener une rétrospective sur la fuite d'un bug critique.

L'automatisation est le valet de parking, pas le chauffeur.

Un mot sur la durabilité

Le rapport suggère des économies en éliminant les tâches manuelles. Économiser de l'argent, c'est bien ; économiser l'énergie, la charge cognitive et le moral, c'est mieux. L'organisation logicielle la plus durable est celle qui :

• Déploie avec peu de carbone et peu de cortisol.
• Apprend plus vite qu'elle ne brûle ses talents.
• Automatise l'ennuyeux et laisse de l'espace à l'humain pour la maîtrise.

Dernières réflexions

Les données Harness ne sont pas un "doom-scroll": c'est un miroir. Oui, la plupart des équipes végètent dans les limbes de maturité intermédiaire. Mais les miroirs ont du pouvoir: dès qu'on voit l'écart, on peut le combler.

Optimisons-nous les pipelines en ignorant les gens?

Poursuivons-nous la vélocité au détriment de la résilience?

Achetons-nous des outils pour masquer les symptômes ou investissons-nous dans la culture pour guérir les causes?

Je sais quelle réponse me garde dans le sport sur le long terme. Et vous? Poursuivons la discussion. Partagez le plus grand défi ou succès DevOps de votre équipe dans les commentaires, et bâtissons ensemble une culture d'ingénierie plus sécuritaire, durable et humaine.

Références:

#	Source	Éditeur
1	The State of Software Engineering Excellence 2025	Harness
2	New report reveals alarming state of software engineering excellence …	PR Newswire
3	Accelerate State of DevOps Report 2023	Google Cloud / DORA
4	Accelerate State of DevOps Report 2024	Google Cloud / DORA
5	Organisations are failing on DevOps experience and maturity	Digit.fyi
6	Measuring GitHub Copilot's Impact on Productivity	Communications of the ACM
7	Predicting Attrition among Software Professionals: Antecedents and …	ACM Digital Library

Is Engineering Excellence an Endangered Species?

A SecDevOps Reflection on the 2025 "State of Software Engineering Excellence" Report

---

Why this report matters to me

If you've followed my writing, you know I treat DevOps (and its grown-up sibling, SecDevOps) as a team sport that balances speed with safety, people with process, and sustainability with shareholder value. When Harness published its State of Software Engineering Excellence 2025 study last week, I grabbed a coffee and devoured all 30-plus pages. 

The headline is blunt: most organisations are still missing the mark on developer experience and DevOps maturity, and they're paying for it in lost productivity, spiralling risk, and frustrated talent. (harness.io)

---

Snapshot of the findings

Trouble spot	Survey data
Slow feedback loops	67 % of teams can't spin up a full build/test environment in 15 minutes
Manual toil	64 % still deploy infra code by hand; 50 % ship apps manually
Code-review drag	61 % wait > 1 day for a review
Quality gates missing	55 % of CI/CD pipelines lack any gating
Incident readiness gaps	52 % lack key tools for incident response
Security blind spots	38 % don't scan builds; 1 in 10 let critical bugs hit prod; median fix time ≥ 7 days for high-severity vulnerabilities.

Add to that:

• Only 29 % have an up-to-date software catalogue.
• Just 19 % provide structured up-skilling for devs.
• A quarter of teams admit > 70 % of user stories lack clear acceptance criteria.

Put bluntly again, the DevOps engine is knocking, the check-security light is flashing, and we're still driving 120 km/h on the 132.

---

Why does this gap persist?

In my consulting rounds I see three recurring anti-patterns:

1. Role-centric "DevOps" – Hiring a "pipeline wizard" and hoping magic trickles outward.
2. Tool-first obsession – Buying best-of-breed widgets without addressing processes or team dynamics.
3. Short-term velocity worship – Shipping features faster today while stacking tomorrow's technical debt (and stress injuries).

The Harness data validates all three: lots of shiny tools, but manual gates; pockets of excellence, but no cross-functional ownership; heroic engineers, but brittle systems.

---

Pros of the current trajectory (yes, there are some)

What's working	Why it still deserves credit
Awareness is up	650 leaders cared enough to benchmark themselves, that's cultural progress.
Platform thinking is emerging	The study champions unified software delivery platforms — exactly what modern SecDevOps preaches.
Security training exists	56 %* are at least training devs annually. Not perfect, but a foundation. (harness.io)
Metrics beat anecdotes	Using a maturity assessment moves the conversation from "feelings" to evidence.

*(Glass-half-full side note: it also means 44 % train less than annually or never.)

---

Cons (the real cost centre)

• Productivity hemorrhage – Every 30-minute context switch waiting for a code review is compound interest on waste.
• Security debt – A week to patch high-sev vulns is an eternity to an attacker; supply-chain exploits don't wait for sprint planning.
• People burnout – Manual deployments and after-hours incidents create the very exhaustion AI tooling claims to cure.
• Innovation drag – Talent stuck chasing broken pipelines isn't inventing the next feature set.

Multiply those by global salary averages and you understand the "millions" Harness flags. (harness.io)

---

A SecDevOps lens on the recommendations

Harness (unsurprisingly) prescribes a platform-centric approach. I agree, with caveats.

Harness prescription	My SecDevOps-flavoured refinement
Automate pipelines end-to-end	Yes, but policy-as-code must gate every stage: SAST, SBOM, IaC drift, secrets scanning, Snyk, SonarQube.
Adopt internal developer portals (IDPs)	Absolutely, but ensure least-privilege defaults and guard-railed self-service to avoid "shadow IT/infra."
Upskill continuously	Non-negotiable. Pair mandatory secure-coding sessions with rotation in incident response to build real empathy.
Measure maturity across five dimensions	Do it, with DORA metrics to keep eyes on throughput and reliability and ideally a SecDevOps lens. (en.wikipedia.org)

---

Culture change beats platform change

You can't secure what you don't understand; you can't automate what you haven't agreed to standardise. That calls for:

• Blameless, brutally honest retrospectives – surface the frictions behind those < 15-minute build failures.
• Shared SLOs – dev, ops, and security owning the same uptime, MTTR, and change-failure goals.
• Sustainability KPIs – track on-call load, after-hours pages, and training hours as first-class metrics, not "nice to haves." (See the emerging Sustainable DevOps research. (arxiv.org) and our article  Sustainability Is the New Performance )

---

People friendliness: the missing variable

The report focuses on dollars and defects. Let's add a human dimension:

• Manual toil = burnout. 
• Waiting on reviews = disengagement. 
• Slow incident resolution = paging the same hero at 3 a.m.

Addressing these isn't just a retention strategy; it's risk management. Tired minds mis-configure prod.

---

My four-point action plan

1. Map the waste Time-in-queue, not lines-of-code, is my leading indicator. If your PRs sit more than 12 hours, fix the feedback loop before buying another scanner.

2. Shift security conversations left Tools catch patterns; humans catch plausibility. Schedule brown-bag threat-model sessions so devs smell danger before a pull request exists.

3. Invest in platform and people equally A robust IDP without a rotation plan is shelf-ware. Pair every new self-service feature with a skills module and a psychological-safety check-in.

4. Have a Maturity Assessment. You don't know how or by whom, please contact us. But you need to know where you are of you intend of getting somewhere.

---

Where AI fits (and where it doesn't)

Copilot-style agents can suggest secure configs and auto-generate tests. But they can't:

• Negotiate acceptance criteria with stakeholders.
• Decide your organisation's risk appetite.
• Hold a retrospective on why a critical bug slipped.

Automation is the valet, not the driver.

A note on sustainability

The study hints at cost savings from eliminating manual tasks. Saving money is great; saving energy, cognitive load, and morale is better. The most sustainable software organisation is one that:

• Deploys with low carbon and low cortisol.
• Learns faster than it burns talent.
• Automates the boring and leaves space for mastery.

Closing thoughts

Harness's data isn't a doom scroll; it's a mirror. Yes, most teams remain stuck in mid-maturity limbo. But mirrors are powerful: once you see the gap, you can close it.

So ask yourself:

Are we optimising pipelines while ignoring people? Are we chasing velocity and missing resilience? Are we buying tools to hide symptoms or investing in culture to cure causes?

I know which answer keeps me in the game for the long haul. What about you? Let's continue this conversation. Share your team's biggest DevOps maturity hurdle or success story in the comments, and let's build a more secure, sustainable, and human-friendly engineering culture together.

References:

#	Source	Publisher
1	The State of Software Engineering Excellence 2025	Harness
2	New report reveals alarming state of software engineering excellence …	PR Newswire
3	Accelerate State of DevOps Report 2023	Google Cloud / DORA
4	Accelerate State of DevOps Report 2024	Google Cloud / DORA
5	Organisations are failing on DevOps experience and maturity	Digit.fyi
6	Measuring GitHub Copilot’s Impact on Productivity	Communications of the ACM
7	Predicting Attrition among Software Professionals: Antecedents and …	ACM Digital Library