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

 

Pourquoi le mythe de la « rockstar Dev(Sec)Ops » persiste

En quelque mots, des raisons fréquentes.

Le badge rêvé des loups technos:

• Crédibilité éclair. Un simple changement de titre LinkedIn et, hop, on devient le/la spécialiste pipelines.
• Paradis du collectionneur d’outils. Kubernetes aujourd’hui, service "mesh" demain : chaque nouvelle courbe d’apprentissage semble propulser la carrière.
• Adrénaline héroïque. Corriger un bug à 2 h du matin rapporte des émojis et une réputation de « solutionneur ».

Le raccourci irrésistible pour les entreprises:

• Un seul cou à pendre. Sur l’organigramme, ça paraît « efficace ».
• Économie apparente. Fusionner Dev, Ops et Sec évite trois embauches distinctes.
• Vitrine marketing. Dire « on fait du DevSecOps » sonne innovant dans un diapo au CA.

Résultat : on recrée exactement ce que DevOps voulait éliminer: les silos et les goulots.

---

Les coûts cachés du modèle “héros”

Risque	Impact	Donnée clé
Facteur-bus = 1	Un congé ou un départ bloque les déploiements.	Définition du bus-factor : un seul imputable = risque maximal. (indeed.com)
Bottlenecks & Burnout	Tout passe dans la file d’attente d’une personne ou d'une équipe.	Burnout massif signalé chez les équipes DevOps “one-man-band”. (devops.com)
Dérive sécurité	Les “gates” tardives stoppent la prod in extremis.	Corriger en prod coûte jusqu’à 30 fois plus cher qu’en dev. (functionize.com)
Illusion de vitesse	Plus d’outils != plus de flux; complexité ↑, débit ↓.	Projets empilant outils = fragmentation coûteuse. (reddit.com)

---

DevOps & SecDevOps bien faits

« Les équipes haute performance sont transverses, outillées en plateforme et pilotées par la donnée. »:  DORA 2024 (kodus.io)

1. Responsabilité partagée. Dev code la fonction, Ops code l’infra, Sec code la politique.
2. Ingénierie de plateforme. Une petite équipe maintient les “paved-roads” (templates, images, portails self-service).
3. Sécurité “shift-left”. SAST, scan secrets et policy-as-code sur chaque pull request.
4. Apprentissage continu. Rétros sans blâme, métriques en boucle vers le backlog.
5. Amélioration guidée par les DORA : Lead Time, Fréquence de déploiement, MTTR, Taux d’échec. Les équipes élites écrasent les retardataires d’un facteur 10–100. (kodus.io)

---

Des métriques qui comptent (pas juste du bruit)

Le plus important, trouvez vous des métriques qui font du sens chez vous. Des exemples classiques sont:

• Fréquence de déploiement – rythme (élite ≈ plusieurs fois/jour).
• Lead Time de idée vers prod (< 1 jour pour les élites).
• MTTR, résilience (< 1 h).
• Taux d’échec: qualité (0–5 %).
• Backlog dette sécu – vulns. critiques vs SLA.
• Indice de fatigue: nbr. alertes hors heures ouvrables.

Reliez-les à des résultats clients ; sinon vous optimisez en vase clos.

---

Ensemble, on s’y met !

1. Tuez le fantasme du héros. Partagez code et astreintes.
2. Mesurez puis améliorez. Un goulot à la fois.
3. Automatisez l’ennuyeux, humanisez le critique.
4. Sécurisez tôt et souvent. Une vuln. fixée en prod coûte 30 x plus. (functionize.com)
5. Pensez plateforme, pas outil-unique. Un “golden path” évite la file de tickets.

Si vous êtes déjà la rockstar isolée : cette feuille de route est votre assurance-vie.
Si vous êtes dirigeant : économiser trois embauches se paie en pannes, amendes et départs.

Commencez petit : mesurez, automatisez, invitez la sécurité à votre prochaine rétro. La haute performance n’est pas héroïque ; elle est habituelle, incrémentale et, surtout, partagée.

Vos vendredis soirs vous diront merci.

Vous êtes prêts pour un plan sans douleur? Contactez nous.

Why the “Dev(SEC)Ops Rockstar” Myth Persists

Why the “DevOps Rockstar” Myth Persists

A Bad­ging Bonanza for Ambitious Engineers

• Instant credibility. One LinkedIn title change, and you’re the go-to guru for pipeline pain.
• Tool-collector’s paradise. Kubernetes today, service mesh tomorrow—learning curves feel like career hacks.
• Hero dopamine. Shipping hot-fixes at 2 a.m. earns high-five emojis and a reputation for “getting things done.”

An Irresistible Shortcut for Businesses

• One neck to wring. Executives like simple org charts; a single “DevOps Department” feels efficient. (medium.com)
• Budget sleight of hand. Blending Dev, Ops, and Sec into a single role avoids hiring three specialists, or so they believe.
• Illusion of modernity. Saying “we’ve adopted DevSecOps” looks innovative in board decks: whether or not practices change.

The result? A fragile setup that contradicts DevOps’ founding principles of shared ownership and flow.

---

The Hidden Costs of the Hero Model

Risk	Why It Hurts	Data Point
Bus Factor = 1	One vacation, resignation or (heaven forbid) illness, stalls releases and repairs.	The bus-factor concept warns that low redundancy is a project-killer. (en.wikipedia.org)
Bottlenecks & Burnout	All changes queue behind a single reviewer/deployer or team.	Elite teams ship 182× more often precisely because work is spread, not centralized. (multitudes.com)
Security Drift	Late “security gates” create surprise blockers.	Fixing a defect in prod costs up to 30× more than in dev. (linkedin.com)
AI Over-hype	Super-charging one person with Gen-AI increases batch size and failure risk.	A 25 % jump in AI use correlates with -1.5 % throughput and -7.2 % stability. (cloud.google.com)

None of this is sustainable; it just hides toil until it explodes.

---

DevOps & SecDevOps Done Properly

“High-performing teams are cross-functional, platform-enabled, and metrics-driven.”: DORA 2024

1. Shared Responsibility. Developers own runtime; operators code infrastructure; security writes policies as code.
2. Platform Engineering. A small team curates paved-roads (templates, golden images, self-service portals).
3. Shift-Left Security. Static analysis, secret scanning, and policy-as-code fire on every pull request.
4. Continuous Learning. Blameless post-mortems feed dashboards and backlog grooming.
5. Data-Driven Improvement. Track Lead-Time, Deployment Frequency, MTTR, and Change-Fail Rate, not vanity stats. Elite performers beat laggards by 1-2 orders of magnitude on all four. (multitudes.com)

Cross-functional teams with these traits are 50 % more likely to succeed. (moldstud.com)

Tes pipelines sont-ils sécurisés ou minent-ils du crypto en douce?

 

En parlant de DevSecOps, vos pipelines sont-ils sécurisés ou produisent-ils des cryptomonnaies illicites?

 Pourquoi la ruée vers l’or CI/CD cible maintenant vos cycles CPU

Au cours des dernières années, les malautrus sont passés de la destruction des vitrines aux caisses enregistreuses. La saveur du "digital skimming" de 2025 est le cryptojacking dans les outils DevOps. Une campagne récemment documentée, dont le nom de code est JINX-0132, analyse Internet à la recherche de grappes HashiCorp Nomad / Consul auto-hébergées, d’API Docker et d’alternatives légères à Git telles que Gitea, s’insère, ou parfois utilise simplement les informations d’identification par défaut, et fait tourner des mineurs XMRig dans vos propres processus CI/CD. Les escrocs exfiltrent le Monero; Vous payez la facture du nuage. Bref, ouch.

Deux faits inconfortables ressortent :

• 25% des environnements infonuagiques exécutent au moins un de ces quatre outils.
• 30% de ces cas sont mal configurés et 5% sont largement ouverts à l’Internet public. (wiz.io, theregister.com)

Cette intersection de popularité et de mauvaise configuration explique pourquoi les plateformes DevOps ont dépassé les serveurs Web sur les listes d’épicerie des attaquants.

Are you a shadow crypto factory?

 

Speaking of DevSecOps, are your pipelines secured or are they making illicit crypto?

DevOps versus DevSecOps, an illustrated example.

So what’s the big deal about DevSecOps?

Why can’t you just explain it?
I can, but first we need to talk about DevOps.

Act I – DevOps, the culture. Not a person.

Contrary to many job ads, DevOps isn’t a title. It’s a way of working that dissolves the wall between those who build software and those who run it. Think of it as a kit of good habits:

• Shared ownership: Dev and Ops solve problems together.
• Automation: Let the pipeline handle repeatable work so humans focus on value.
• Continuous feedback: Ship small, ship fast, break less.
• Process before product: Tools only matter if they fit the people and the flow.

Teams that embrace this cultural shift ship faster and with fewer outages: something the DORA State of DevOps reports have measured for years.^[1]

Rule of thumb
Do the right thing at the right time.
Simple to say, tricky to master.

Act II – Adding the SEC

All we do is extend the same mindset: if Ops belongs in the conversation from day one, so does Security. DevSecOps weaves security controls, tests and governance into every stage of the pipeline instead of treating them like an end-of-cycle audit.^[2]

Act III – A walk through the pipeline

(Click the picture to enlarge.)

Figure 1 – Sample Dev + Sec + Ops pipeline.

Stage	Why it exists	Who it shields
Experiment	Fail fast on a branch or local sandbox.	Literally everyone else.
Dev	Prove the change plays well with codebase, config & IaC.	Fellow engineers, OPS.
QA	Automated & exploratory tests, data seeding, basic gates.	Testers and early adopters.
UAT	Mirror prod as closely as budgets allow; performance & business acceptance.	Business stakeholders.
Prod	Final gate, release notes, infra diffs.	Real customers & revenue.

Security questions ride along:

• Experiment → Dev – Static analysis, secret scanning.
• Dev → QA – Dependency checks, container image signing.
• QA → UAT – Dynamic (DAST) tests, infra-drift detection.
• UAT → Prod – Compliance artefacts, runtime policy enforcement, configuration concerns.

We didn’t add environments: we baked security into the ones we already have.

Act IV – The big DevSecOps change.

Ready for the twist?

We change … nothing.

Stages, people and cadence stay the same. What changes is the definition of done. Security requirements become first-class citizens—groomed, coded, tested and deployed beside features. It feels almost boring, which is exactly the point: security becomes routine, not roulette.

Conclusion – Why this matters, now!

• High-performing teams that couple culture, automation and security outperform their peers on stability and speed.^[1]
• Regulators and customers expect proof of software supply-chain hygiene, continuously.
• Talent retention improves when Ops & Security aren’t firefighting at 2 a.m.

Your call to action

3. Invite security to the daily stand-up. Today. Zero slide decks required.
4. Automate one pain-point. 
5. Add one security gate: Owasp, SAST, SCA or container scan, before the next sprint review.
6. Share this article with a teammate and ask what “doing the right thing at the right time” means to them.

DevSecOps isn’t a new religion; it’s DevOps done right. Start small, iterate, and let security become as invisible, and indispensable as, version control.

Ready to drop that wall for good? Let’s ship, safely. Questions let's have it below.

---

References

1. Google Cloud / DORA – State of DevOps Reports
2. Red Hat – What is DevSecOps?
3. AWS – DevSecOps Explained

© 2025 JPSoftWorks. All rights reserved.

DevOps et SecDevOps version illustrée

Alors, c’est quoi "la grosse affaire" avec DevSecOps ?

Pourquoi est-ce si difficile à expliquer ?
Je peux le faire, mais parlons d’abord de DevOps.

Acte I – DevOps, la culture qu’on ne peut pas simplement "embaucher"

Contrairement à bien des offres d’emploi, DevOps n’est pas un titre ou un rôle. C’est une façon de travailler qui fait tomber le mur entre celles et ceux qui créent les logiciels et celles et ceux qui le font tourner, qui l'exploitent. Pensez à DevOps comme si c'était un ensemble de bonnes habitudes :

• Responsabilité partagée: Dev et Ops résolvent les problèmes ensemble.
• Automatisation: Le pipeline prend en charge le répétitif ; les humains se concentrent sur la valeur.
• Rétroaction continue: Livrer petit et vite, c’est moins risqué que tout livrer d’un coup.
• Le processus avant l’outil: Les outils ne comptent que s’ils servent l’équipe et son flux.

Les équipes qui adoptent ce changement culturel livrent plus vite et avec moins d’incidents, comme le démontrent les rapports DORA State of DevOps année après année.^[1]

Règle d’or
Faire la bonne chose au bon moment.
Simple à dire, difficile à maîtriser.

Acte II – Ajouter le SEC

On étend la même logique : si Ops est dans la discussion dès le jour 1, la Sécurité y a sa place aussi. DevSecOps intègre contrôles, tests et gouvernance de sécurité à chaque étape du pipeline, au lieu d’un audit final hors délais.^[2]

Acte III – Parcours du pipeline

(Cliquez sur l’image pour l’agrandir .)

Figure 1 – Exemple de pipeline Dev + Sec + Ops.

Étape	Pourquoi elle existe	Qui elle protège
Expérimentation	Échouer vite sur une branche ou dans un bac à sable local.	Pratiquement tout le monde.
Dev	Vérifier l’intégration avec le code, la config et l’IaC.	Les autres ingénieurs.
QA	Tests automatisés et exploratoires, jeux de données, portes de contrôle.	Testeurs et premiers utilisateurs.
UAT	Imiter la prod autant que le budget le permet ; perf. et validation métier.	Parties prenantes d’affaires.
Prod	Dernière porte, notes de version, écarts d’infrastructure.	Clients réels et revenus.

Les questions de sécurité voyagent avec l’application :

• Expérimentation → Dev — Analyse statique, détection de secrets.
• Dev → QA — Vérif. de dépendances, signature d’images conteneurs.
• QA → UAT — Tests dynamiques (DAST), détection de dérive infra.
• UAT → Prod — Artefacts de conformité, politiques à l’exécution.

Nous n’avons pas ajouté d’environnements: nous avons "scotché" la sécurité dans ceux qui existaient déjà.

Acte IV – Le grand changement DevSecOps.

Prêt·e pour le punch ?

On ne change… rien.

Les étapes, les gens et la cadence restent les mêmes. Ce qui change, c’est la définition de “fait” (Definition of done, ou DoD). Les exigences de sécurité deviennent des citoyens de première classe: planifiées, codées, testées, déployées avec les fonctionnalités. Ça paraît presque ennuyeux ; c’est justement le but : la sécurité devient routine, pas roulette russe.

Conclusion – Pourquoi c’est crucial maintenant

• Les équipes qui combinent culture, automatisation et sécurité surpassent leurs pairs en stabilité et vitesse.^[1]
• La gouvernance, les lois et les clients exigent désormais une hygiène de la chaîne de livraison logicielle, en continu.
• La rétention des talents s’améliore quand Ops et Sécurité ne sont pas en mode incendie à 2 h du matin.

Votre appel à l’action:

1. Invitez la sécurité au stand-up quotidien. Dès aujourd’hui. Pas besoin de diapos.
2. Automatisez une "épine dans le pied"
3. Ajoutez un seul contrôle de sécurité: Owasp, SAST, SCA ou scan de conteneur, avant la prochaine revue de sprint.
4. Partagez cet article avec un·e collègue et demandez-lui ce que « faire la bonne chose au bon moment » signifie pour elle ou lui.

DevSecOps n’est pas une nouvelle religion ; c’est du DevOps bien fait. Commencez petit, itérez, et laissez la sécurité devenir aussi invisible, et indispensable, que Git.

Prêts·es à faire tomber le mur pour de bon ? Livrons, en toute sécurité. Laissez vos question ci-bas!

---

Références

1. Google Cloud / DORA – Rapports « State of DevOps »
2. Red Hat – Qu’est-ce que DevSecOps ?
3. AWS – DevSecOps expliqué

© 2025 JPSoftWorks. Tous droits réservés.

The DevSecOps Manifesto, Le Manifesto DevSecOps

We have agreed and hold these ideals as our own:

We strive to do the right thing at the right time. And the wrong ones too.

We want to improve: our work, our customer satisfaction and indeed our lives.

We live by the ideal of: work smarter and not harder

We are collectively responsible for our success. Which means we are collectively responsible for everything.

We do not need unanimity to have an agreement. We seek a consensus, but not at all costs.

It is better to make steady slow progress than being late for the sake of perfection.

_____________________________________________

 

There is no point in blame for failure. Failure is expected and it is part of the process.

We put safeguards that so that each step taken is a step forward. Measured and secured.

We agree that we must find an or some objective metrics to measure our success.

The determination of these measures will be ours but also accepted by our customers or representatives.

We think that transparency and visibility of our progress, are necessary allies.

 

_____________________________________________

 

We are slave to constraints and cannot and will not encourage bottlenecks

We try to understand our coworkers as best we can, roles, ambitions, expertise and all.

We design our work and processes to avoid single points of failure.

We believe that security is quality and there is no quality without security.

We accept that security is everybody's responsibility as we are responsible for everything.

 

_____________________________________________

 

This is our guide, this is our convention. If these ideals change it will be because we agree.

 

Nous avons convenu que nous tenons à ces idéaux comme étant les nôtres:

Nous avons la volonté de faire les bonnes choses au bon moment. Les mauvaises aussi.
Nous voulons nous améliorer: notre travail, la satisfaction de nos clients et en effet nos vies.
Nous croyons que bien travailler ne veut pas dire travailler plus.
Nous sommes tous responsables de notre succès. Ce qui veut aussi dire que nous sommes tous responsable de l'ensemble de notre œuvre.
Nous n'avons pas besoin de l'unanimité pour arriver à un accord. Nous désirons un consensus, mais pas à tout prix.
Il es plus important d'avancer un peu assurément, que de tarder pour le bénéfice de la perfection.

_____________________________________________

Il ne vaut rien de blâmer. L'échec fait partie du processus et est prévu.
Nous sécurisons nos processus pour qu'ils soient robustes et adoptés en fonction du progrès mesuré.
À cette fin nous convenons d'être mesurés de façon objective et quantitative.
Les métriques qui nous mesurent seront personnalisés à nous, mais acceptés par nos clients ou représentants.
La transparence et la visibilité de notre progrès, sont des alliés indispensables.

_____________________________________________

 Nous sommes tous esclaves des contraintes. Nous ne sommes ni tenus ou n'encourageons pas de forcer les goulots d'étranglement.

Nous voulons bien comprendre nos collègues, leur rôles, leurs ambitions, leurs expertises et tout.
Notre travail et nos processus sont réfléchis afin d'éviter les points de défaillance uniques.
Il n'y a pas de qualité sans la sécurité. Un produit de qualité a, la sécurité à sa base.
Nous sommes tous responsable de la sécurité. Étant dit préalablement que nous étions tous responsable de tout.

 _____________________________________________

Ceci est notre guide et notre convention. Si ces idéaux changent, ils l'auront fait par accord commun.

SecDevOps ou pas SecDevOps? C'est même pas une question!

SecDevOps + Zero-Trust : guide coquin pour les équipes qui « font déjà du DevOps »… ou pas !

TL;DR  On ne cherche pas à remplacer DevOps; on l'enveloppe dans une armure fluo qui bloque ou révèle le risque, tout en laissant la gang à l’intérieur danser comme si c'etait 1999.

---

Qu’est-ce que SecDevOps, au juste ?

• DevOps : faire circuler la valeur vite, apprendre, recommencer (« vraiment TLDR »).
• SecDevOps : même chose, mais on branche des capteurs de risques dans la plomberie pour que le danger avertit avant de mordre. (Encore plus de shift-left !)
• Zero-Trust : « Ne jamais faire confiance, toujours vérifier »… appliqué aux paquets, jetons, conteneurs, bref tout SAUF l’intention de vos collègues. Réseaux parano: humains optimistes.

Ensemble, ça donne un modèle de capacités qui se branche sur Scrum, Kanban, GitOps, SAFe, peu importe le beat que votre organisation suit, sans exiger une nouvelle religion.

---

Les quatre principes (gentiment) irrévérencieux

1. Tout ce qui bouge est journalisé, scanné ou sinon gueulé. Commits, conteneurs, changements IAM, on s’en fiche de qui a appuyé sur Enter.
2. Les garde-fous valent mieux que les gates (non, pas celles de Bill !). Une image de base endurcie évite bien des « oups »; un gros bouton rouge « ÉCHEC » un vendredi 16 h, ça fait grincer des dents.
3. Zero-Trust du système, confiance totale envers les humains (au boulot). On fait tourner les jetons aux heures, mais on fait tourner le blâme hors du post-mortem.
4. La visibilité = l’amour (gardez quand même vos vêtements). Si un risque peut se cacher, un succès aussi. Les tableaux de bord montrent le flux et les lacunes côte à côte. Les équipes avec une vraie sécurité psychologique et de bons métriques DORA surclassent leurs pairs.

---

Ça remplace DevOps ?

Ben non, c’est DevOps PLUS.
Imaginez DevOps comme un téléphone intelligent ; SecDevOps est l’étui blindé extra-robuste. Vos apps préférées tournent toujours, mais l’appareil survit aux chutes, aux cafés renversés et au hacker occasionnel.

Constat terrain	Quoi faire
Vous avez déjà un CI/CD	Greffez les contrôles de sécurité dans les mêmes étapes. Gardez la culture du "green bar", ajoutez juste une touche de violet pour les passes à la sécurité.
Les Ops craignent la surcharge	Automatisez d’abord, annoncez ensuite. Si le scanner réussit en silence 99 % du temps, personne ne crie.
La Sécurité redoute le « Far West »	Offrez-leur des tableaux de bord en lecture seule et un droit de veto sur les exceptions, les changements non-documentés, pas sur chaque déploiement.

---

Zero-Trust sans casser l’ambiance

Pilier Zero-Trust	Traduction « humaine-friendly »	Garde-fou pas gossant
Vérifier explicitement	« On te fait confiance… mais on double-vérifie le système. »	Toutes les requêtes API se ré-authentifient en douce; les échecs s’affichent à côté du compte de tests unitaires.
Moindre privilège	« Un plus petit rayon d’explosion = moins d’appels à 3 h du mat. »	Rôles « PIM » de 2 heures; l’audit se publie dans #sec-télémétrie.
Présumer l’intrusion	« Curiosité plutôt que blâme. »	Jeux de guerre trimestriels : fuite de faux secrets, beignes pour les gagnants, pas de recherches de coupables.

---

Starter kit (sprint d’une journée: avec zéro échantillon de code, promis !)

1. Activez les scanners intégrés. GitHub Advanced Security, SAST GitLab, analyseurs Azure DevOps, SonarQube… prenez ce que votre dépôt offre déjà gratuitement.
2. Montez un « Risk Radiator ». Un panneau Grafana interne qui fusionne déploiements, vulnérabilités et incidents en une vue bien bruyante et fière.
3. Activez les rôles Just-In-Time. Utilisez la fonction JIT/PIM de votre cloud pour que n’importe quel·le coéquipier·ère obtienne un accès temporaire sans passer par le service desk.
4. Planifiez une journée Purple-Team.* Un après-midi, simulez une fuite de jeton et exercez-vous à la trouver et à la corriger ensemble. Top-là: obligatoire.

*Bleu + Rouge = Purple (Violette) au cas ou c'est pas clair...

---

Métriques qui comptent (et qui gardent tout le monde honnête)

Flux	Sécurité	Culture
Gestion du changement	MTTR-V (correction des vulns)	Nb d’humains uniques ayant fermé un billet sécurité
Fréquence de déploiement	% de sessions privilégiées qui expirent auto	Nb de « kudos » pour détection de risque précoce
Points d’histoire livrés	Nouvelles mesures de sécurité mises en place	Amélioration continue documentée

Si un indicateur monte les équipes l’une contre l’autre, digérez le et jetez-le. S’il déclenche la collaboration, gardez-le.

---

Dernier mot

SecDevOps + Zero-Trust complète DevOps comme la ceinture de sécurité complète la voiture sport : la balade reste délirante, les accidents font moins mal, et personne ne prétend que la ceinture « remplace » le moteur.

Lancez-vous avec un scanner de vulnérabilités, un tableau de métriques et PIMez vous. Laissez les données parler, laissez les humains rire, et observez la vélocité sécuritaire devenir la nouvelle norme.

Allez hop! Ajoutez cette étincelle violette à vos pipelines, votre futur vous vous dira merci.

Vous voulez en parler? Pour en savoir plus? Contactez-nous, dans la section des commentaires ci-dessous.

To SecDevOps or not to. It isn't even a question.

SecDevOps + Zero-Trust: a Cheeky Field Guide for Teams That Already “Do DevOps”...or dont...

TL;DR — We’re not trying to replace DevOps, we’re giving it a shiny exoskeleton that blocks or exposes risk and still lets the people inside, boogie like it's 1999.

 

---

What is SecDevOps, Really?

• DevOps: make value flow fast, learn, repeat. really TLDR.

• SecDevOps: do the same thing but wire risk-sensors into the plumbing so danger lights up before it bites. (Shift left... again)

• Zero-Trust: “Never trust, always verify”… applied to packets and tokens, code, containers, everything, EXCEPT colleagues’ motives. In other words, paranoid networks, optimistic humans. (NIST, csrc.nist.gov)

Put them together and you get a capability model that snaps onto Scrum, Kanban, GitOps, SAFe, whatever rhythm your org already claps to, without demanding a brand-new religion.

---

The Four Cheeky Principles

1. Everything That Moves Is Logged, Scanned, or Yelled At
   Commits, containers, IAM changes, doesn’t matter who hit Enter.

2. Guardrails Beat Gates (no, no, not Bill!)
   A pre-hardened base image prevents oopsies; a red “BLOCKED” button at 4 p.m. Friday enrages engineers.

3. Zero-Trust the System, Full-Trust the Humans, at work.
   We rotate tokens every hour but rotate blame out of the post-mortem.

4. Visibility = Love (Keep your clothes on, though)
   If a risk can hide, so can a win. Dashboards show flow and flaws side-by-side. Elite teams with strong psych-safety and good metrics outperform their peers on every DORA KPI. (InfoQ, Kodus)

---

Does This Replace DevOps?

Nope, ­it’s DevOps Plus.
Think of DevOps as the smartphone; SecDevOps is the ruggedized case and screen protector. Your favourite apps still run, but the device survives drops, spills, and the occasional hacker.

Reality Check	What to Do
You already have CI/CD	Bolt security checks into the same pipeline stages. Keep the green bar culture, just add a “purple sparkle” for security passes. (explanation forthcoming)
Ops teams worry about extra toil	Automate first, announce second. If the scanner’s silent-success rate is 99 %, nobody screams.
Security fears a “Wild West”	Give them read-only dashboards and veto power on exceptions and undocumented changes, not on every deploy.

---

How Zero-Trust Fits Without Killing the Vibe

Zero-Trust Pillar	Human-Friendly Translation	Non-Annoying Guardrail
Verify Explicitly	“We trust you, we double-check the system.”	All API calls re-auth transparently; failure shows up next to the unit-test count.
Least Privilege	“Smaller blast-radius = fewer 3 a.m. calls.”	2-hour click-to-elevate roles; audit trail posts to #sec-telemetry.
Assume Breach	“Curiosity over blame.”	Quarterly game-days inject fake secrets; winners get doughnuts, not finger-pointing.

---

Starter Kit (One-Day Sprint, No Code Samples: Promise!)

1. Turn On Built-In Scanners
   GitHub Advanced Security, GitLab SAST, Azure DevOps Analyzers, SonarQube, or whatever your repo already gives you for free.

2. Spin Up a “Risk Radiator”
   Internal Grafana panel that glues deployment, vulnerability, and incident metrics into one loud, proud place. Keep granular data about projects for diagnostics, but display the aggregate.

3. Enable Just-In-Time Roles
   Use your cloud’s JIT/“break-glass”/PIM feature so any teammate can get short-lived access without service-desk limbo.

4. Schedule a Purple-Team* Game-Day
   One afternoon, fake a token leak and practise finding & fixing it together. High-fives mandatory.

*Red+Blue = Purple, in case you needed the explanation

---

Metrics That Matter (and Keep Everyone Honest)

Flow	Safety	Culture
Lead Time for Change	MTTR-V (vuln fix)	# of unique humans who closed a security ticket
Deployment Frequency	% privileged sessions auto-expire	# shout-outs for spotting a risk early
Story points delivered	New safety measures put into place	continuous improvement

If a stat can pit teams against each other, digest it and dump it. If it sparks joint problem-solving, keep it.

---

Final Nudge

SecDevOps + Zero-Trust complements DevOps the way seatbelts complement sports cars: the ride stays thrilling, the crashes hurt less, and nobody argues that belts “replace” engines.

Start with one scanner, one metric board, and one JIT role.
Let the data speak, let the humans laugh, and watch safe velocity become the new normal.

Now go forth and add that purple sparkle to your pipelines: your future self already thanks you.

Want to talk about it? To know more? Hit us up, in the comment section below.

Faire "Agile" de la bonne façon : les points et le contrat.

Au-delà des chiffres: Comprendre les Story Points comme un contrat tacite dans Azure DevOps: Adopter l'observabilité & SecDevOps

Introduction: Mise en contexte

Soyons honnêtes: l'idée des "story points" peut sembler un peu… eh bien, absurde au premier abord. C'est comme essayer de mesurer le ressenti d'une bonne tasse de café avec une règle. Mais les story points ne visent pas une mesure précise. Ils sont un outil de communication, de collaboration et, surtout, de compréhension de la complexité relative des tâches. Mais, si on les fait correctement, il ne s'agit pas de mesurer le temps ; il s'agit de tenir une promesse. Une promesse tacite, en fait, celle qu'on fait d'un coup d'œil complice et d'un haussement d'épaules un peu embarrassé. Il s'agit d'estimer l'effort, pas le temps. Utiliser les story points nous permet de prioriser efficacement et de suivre notre vélocité: en gros, à quelle vitesse nous avançons. C'est une approche étonnamment utile et c'est une pierre angulaire du DevSecOps.

L'écosystème interconnecté: Observabilité & SecDevOps

Imaginez un orchestre chaotique: où chacun joue un instrument différent, à n'importe quel cadence et où personne ne sait ce que font les autres. C'est à ça que ressemble le développement d'application sans un bon système. Azure DevOps, en revanche, ressemble à une symphonie magnifiquement orchestrée. Azure Boards (pour la planification), Azure Repos (pour le code), Azure Pipelines (pour les compilations et les déploiements) et Azure Artifacts (pour la gestion des packages): ils communiquent tous ensemble. Les changements dans le plan sont immédiatement reflétés dans le code, les compilations et les déploiements. Cela crée une boucle de rétroaction: un élément essentiel pour l'observabilité.

Voyez les choses de cette façon: un petit bug introduit pendant une compilation est immédiatement signalé, et l'équipe peut rapidement annuler les modifications. C'est un principe fondamental du SecDevOps: la sécurité proactive, la surveillance continue et la réponse rapide. Sans cette intégration, vous êtes essentiellement à l'aveugle. C'est comme essayer de réparer une fuite de canalisation, mais cette fois-ci avec une lampe de poche. La visibilité en temps réel est essentielle !

Observabilité et SecDevOps: Maintenir le contrat vivant

Sans observabilité, la capacité à comprendre ce qui se passe à l'intérieur de votre système, ce contrat tacite est fragile. Vous devez savoir pourquoi les choses se produisent. La surveillance, la journalisation et le traçage sont vos alliés. Les pratiques SecDevOps ne consistent pas seulement à ajouter de la sécurité ; elles visent à construire la résilience et la compréhension. C'est autant une question de manière de travailler que de ce que nous livrons !

Alors, qu'est-ce qu'une User Story ? (Et pourquoi c'est un accord secret)

Une user story, au fond, est un petit extrait de conversation. Ce n'est pas un document de spécification détaillé. Ce n'est pas un plan. C'est un point de départ. Une bonne user story ressemble à ceci: "En tant que [rôle utilisateur], je veux [objectif] afin que [bénéfice]." Exemple: "En tant que client, je veux pouvoir réinitialiser mon mot de passe afin de pouvoir accéder à mon compte si je l'oublie." Simple, non ?
Mais voilà le truc: ce ne sont pas seulement les mots. C'est l'accord implicite qui suit. C'est là que le côté "tacite" entre en jeu. C'est comme accepter de se voir pour un café: vous n'écrivez pas l'itinéraire exact, la température ou la marque de café préférée. Vous acceptez simplement de vous retrouver. Puis, vous vous débrouillez. Une user story bien rédigée est la base de cet accord.

L'art de moins de stress, plus de promesses

La documentation agile, et je ne parle pas d'un dossier de 100 pages, je parle de tout ce que l'on place simplement dans nos tableaux de travail, vise en réalité à réduire la pression sur l'équipe. Soyons réalistes, courir sans cesse après cette "spécification parfaite" ne fait qu'engendrer de l'anxiété. C'est un jeu de raffinement sans fin, et honnêtement, c'est épuisant. En adoptant une approche légère, on déplace l'accent de la documentation méticuleuse de chaque détail vers la simple capture d'assez d'informations pour que tout le monde reste aligné. Il s'agit d'une compréhension partagée, pas d'un contrat rigide.

Les éléments qui "verrouillent" la spécification (et pourquoi vous ne devriez pas les ignorer)

Décomposons ce qui fait réellement qu'une user story "tient". C'est plus que le format de base. Voici ce qui doit être présent pour que tout le monde soit sur la même longueur d'onde et pour créer cet accord puissant et silencieux :

• Critères d'acceptation: Ce sont les règles de l'accord. Ce sont les éléments qui doivent être vrais pour que la story soit considérée comme "terminée". Ils ne sont pas optionnels. Exemple: "Étant donné que j'ai saisi une adresse e-mail valide, lorsque je clique sur ‘Réinitialiser le mot de passe', alors je devrais recevoir un e-mail avec un lien pour réinitialiser mon mot de passe."
• Définition de Terminé (DoD): C'est la liste de contrôle plus large: scans de sécurité, revues de code, tests d'intégration, etc. C'est ce qui assure que la story est véritablement complète et fiable.
• Valeur d'affaires": C'est la partie "… afin que …". C'est pourquoi nous faisons cela. C'est le lien avec l'objectif "business". Sans cela, vous construisez seulement des belles choses creuses sans but.
• Considérations techniques: Parfois, l'équipe doit discuter des implications techniques. Ce n'est pas nécessairement une partie de la user story, mais il est important de le reconnaître.

Story Points: Engagements, pas échéances

Oubliez l'idée de mapper les story points aux heures. C'est une recette pour la frustration. Les story points sont des estimations relatives: parlons-nous d'une "petite modification" ou d'une "refonte majeure" ? Considérez-les comme un moyen de communiquer la complexité relative et le risque. Encore une fois, nous n'essayons pas de quantifier l'effort (c'est un piège !). Nous essayons d'établir une mesure relative de complexité et de risque. Une story estimée à environ 8 points est à peu près aussi complexe qu'une story à 13 points. L'important n'est pas le chiffre lui-même, mais la compréhension partagée qu'il représente.

La règle des 13 points: Quand décomposer

Voici un petit secret: tout ce qui est estimé à 13 ou plus devrait probablement être décomposé. Sérieusement. C'est un signal d'alarme rouge flamboyant qui vous dit que vous vous apprêtez à vous lancer dans quelque chose de potentiellement épineux. Les stories volumineuses sont souvent le symptôme d'un glissement de périmètre ou d'un manque de clarté.

Voyez les choses ainsi: si vous estimez une story à 13 points, vous dites essentiellement "Je ne suis pas tout à fait sûr de ce dans quoi je m'embarque." Et c'est tout à fait correct ! Mais cela doit être traité. Ne vous contentez pas de la confier à un développeur et d'espérer le meilleur.

La séquence de Fibonacci: Pourquoi une échelle relative ?

Vous avez probablement entendu l'histoire de Ron Jeffries et de la séquence de Fibonacci. Il essayait d'estimer l'effort sur un projet, et il s'est rendu compte que les tâches se répartissent souvent en catégories distinctes: certaines sont minuscules, d'autres énormes. La séquence (1, 2, 3, 5, 8, 13…) est une façon naturelle de représenter cela. C'est comme dire "D'accord, cette tâche est à peu près de la taille d'un petit chien, celle-ci est de la taille d'un Labrador…"

La valeur d'un point: Échelle, pas absolus

Ne tombez pas dans le piège de penser qu'un "3" signifie toujours la même chose. Lors du Sprint 1, un "3" peut être une entreprise énorme: réécrire une partie conséquente de l'application. Mais au Sprint 5, c'est probablement une tâche standard. La valeur d'un point se solidifie avec le temps à mesure que l'équipe acquiert de l'expérience et une compréhension partagée. Il s'agit de suivre la vélocité: la tendance de la rapidité avec laquelle vous avancez, pas d'un objectif rigide. Considérez cela ainsi: un marathonien expérimenté connaît mieux son rythme qu'un débutant.

Rigueur et flexibilité: Trouver l'équilibre

Bien qu'il soit important d'être réfléchi dans nos estimations, ne vous enfoncez pas dans les détails. La rigueur et la flexibilité doivent être équilibrées. Utilisez des techniques comme les rétrospectives de sprint et le planning poker pour affiner vos estimations au fil du temps. Adoptez l'auto-organisation et l'adaptation. N'oubliez pas que l'objectif est de communiquer efficacement et de délivrer de la valeur.

Azure Boards, Repos, Pipelines, Artifacts: Construire les "dents"

C'est là que la magie opère. Lorsque vous connectez vos Azure Boards, vos Git Repos, vos Pipelines et vos Artifacts, vous intégrez les dents dans ce contrat tacite.

• Azure Boards: Fournit le cadre pour la story, le backlog et la planification du sprint.
• Repos: La source de vérité pour le code.
• Pipelines: Automatisent le processus de compilation, de test et de déploiement, garantissant une livraison cohérente.
• Artifacts: Le livrable empaqueté, prêt à être déployé.

Cet écosystème intégré transforme une promesse vague en un résultat concret et vérifiable. Les pratiques de sécurité et DevOps (SecDevOps) sont cruciales ici. Pensez aux scans de sécurité automatisés dans vos pipelines, aux évaluations de vulnérabilité et à la surveillance continue.

Conclusion

En résumé: Les story points ne servent pas à mesurer le temps. Ils visent à instaurer la confiance, à favoriser la collaboration et à transformer des intentions vagues en résultats concrets. En connectant vos outils et en adoptant SecDevOps, vous pouvez transformer votre processus agile d'une série de suppositions en un pipeline de livraison fiable et reproductible.

Et en fin de compte, les story points sont un outil de communication et de collaboration, pas un système de mesure rigide. Adoptez l'approche du "contrat tacite": mettez l'accent sur la compréhension partagée et laissez les chiffres vous guider. Ne vous focalisez pas sur les chiffres ; concentrez-vous sur la livraison de la valeur.

Prêt à transformer vos pratiques DevSecOps ? Laissez-nous un commentaire ci-dessous pour planifier une consultation et découvrir comment nous pouvons vous aider à construire une équipe plus efficace et collaborative.

Prochainement: SecDevOps et Ingénierie de Plateforme.