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)

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.

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

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

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

1 · Pourquoi c'est important pour moi

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

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

2 · L'histoire se ressemble

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

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

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

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

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

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

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

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

6 · Appel à l'action

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

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

 *Rédigé en collaboration avec ChatGPT 3o

LLMs ≈ Pocket Calculators for the Mind

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

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

 

1 · Why this matters to me

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

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

2 · History keeps rhyming

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

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

3 · LLMs through a human-centric lens

• Augment, don’t abdicate

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

• Traceability by design

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

• Privacy & ethics guardrails

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

• Continuous learning loop

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

4 · Why fears persist—and how to answer them

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

5 · Guiding principles I follow

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

6 · Call to Action

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

*Written in collaboration with ChatGPT 3o

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

About JP

Jean-Paul Lizotte (« Jaypee »)

SecDevOps Transformation Leader | Zero-Trust & Compliance Automation | 30 + years in IT driving resilient, people-centric delivery

I build high-trust, Zero-Trust engineering cultures. From programming Microsoft BASIC in 1981 to leading SOC 2 Type II attestations, my career arcs around one idea: technology should empower people, not become their bottleneck

Today I coach organisations out of “guru dependency” and into collaborative, self-healing SecDevOps ecosystems that cut lead-time, raise security posture, and make audits almost invisible to engineers.

Signature Results

• SOC 2 Type II readiness in under 12 months – Automation and coordination of implementation of Audit controls.
• 45 % fewer production defects after embedding SAST / DAST / IaC gates into CI / CD.
• Daily releases down from bi-weekly by coaching five cross-functional squads on trunk-based development and feature flags.
• Hub-and-spoke Azure landing zone Bicep Deployment, with policy-as-code and private endpoints, now hosting 30 + workloads.

Playbook

1. Strategy & Governance – Map business risk to guard-rails; bake compliance into workflow.
2. Automation – Everything-as-Code: pipelines, policies, infrastructure.
3. Culture – Psychological safety, shared ownership, continuous feedback loops, security baked-in everything.

Core Competencies

• SecDevOps Leadership & Cultural Transformation
• Zero-Trust Architecture & SOC 2 Type II Compliance
• CI / CD & IaC: Azure DevOps · GitHub Actions · Bicep · Docker / AKS, SonaQube, Snyk
• Multi-Cloud & Hybrid Governance (Azure-first, some AWS)
• Data & Pipeline Security: SAST · DAST · Secrets Management · SIEM log centralisation
• Coaching & Mentoring cross-functional squads

Recent Roles

Emyode | Certified B Corp 

7 years 10 months 

SecDevOps Practice Leader | Deputy CIOSO 

May 2024 - May 2025 (1 year 1 month) 

Montreal, Quebec, Canada 

As Deputy to the CIOSO, I contributed to the company’s operational security strategy by identifying systemic risks, establishing process controls, and implementing scalable governance frameworks across development teams. A key part of this role involved leading the implementation of Emyode’s SOC 2 security readiness program, aligning teams and operations with rigorous audit controls and evidence-based compliance standards. As SecDevOps Practice Leader, I fostered a security-first culture by embedding security at every stage of the SDLC. I coached cross-functional teams on secure automation, threat modeling, and continuous improvement— transforming DevOps maturity into measurable business value. Key Contributions: Operationalized the SOC 2 readiness initiative, from gap analysis to policy implementation and evidence collection, ensuring audit readiness.

• Designed DevSecOps pipelines with embedded quality and compliance checks. 
• Led security training, risk workshops, and architecture reviews with both internal teams and external clients. 
• Established metrics and dashboards for real-time security KPIs and remediation tracking. 
• Acted as an executive liaison to support communication between stakeholders and security teams. Drove enterprise SOC 2 program, instituted Zero-Trust controls, and centralised observability