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

De quoi s’agit-il?

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

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

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

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

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

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

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

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

Posture 2: DevOps comme paradigme culturel

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

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

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

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

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

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

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

Ma propre évaluation des deux approches

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

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

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

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

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

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

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

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

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

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

À venir :

Agentic SecDevOps, est-ce pour vous?

The Two Faces of DevOps: Tech guru vs. Culture

What is all this about?

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

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

Posture 1: DevOps as a Specialized Role

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

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

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

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

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

---

Posture 2: DevOps as Cultural Paradigm

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

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

Moreover, in 2025 we’re seeing DevOps evolve:

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

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

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

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

---

My own evaluation of the Two Approaches

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

---

My Perspective: Sustainability First

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

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

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

---

Riddle me this: Which Offers Better Value?

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

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

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

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

Coming up next:

Agentic SecDevOps, is it for you?

La pérennité est la nouvelle performance

Nous parlons sans cesse de performance :

• Vitesse
• Scalabilité
• Productivité

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

Est-ce durable ?

---

L’illusion d’une croissance infinie

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

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

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

---

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

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

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

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

Nous voulons aussi savoir si :

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

---

Concevoir pour l’endurance, pas seulement la vitesse

Un leadership technologique durable implique :

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

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

---

Que signifie vraiment la croissance ?

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

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

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

---

Vers une nouvelle définition de la valeur

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

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

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

---

Et si tout le reste était égal ?

Imaginez :

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

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

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

---

Parlons pérennité

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

---

Ce qui a changé ?

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

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

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

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

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

1 · Pourquoi c'est important pour moi

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

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

2 · L'histoire se ressemble

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

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

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

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

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

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

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

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

6 · Appel à l'action

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

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

 *Rédigé en collaboration avec ChatGPT 3o

LLMs ≈ Pocket Calculators for the Mind

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

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

 

1 · Why this matters to me

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

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

2 · History keeps rhyming

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

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

3 · LLMs through a human-centric lens

• Augment, don’t abdicate

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

• Traceability by design

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

• Privacy & ethics guardrails

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

• Continuous learning loop

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

4 · Why fears persist—and how to answer them

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

5 · Guiding principles I follow

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

6 · Call to Action

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

*Written in collaboration with ChatGPT 3o

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

Sustainability Is the New Performance

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

How fast?
How scalable?
How productive?

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

Is it sustainable?

 

---

The Illusion of Infinite Growth

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

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

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

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

---

Sustainability as a First-Class Metric

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

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

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

We mean:

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

---

Designing for Endurance, Not Just Velocity

Sustainable tech leadership means:

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

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

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

---

What Does Growth Really Mean?

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

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

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

---

A New Definition of Value

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

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

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

That’s not forward.
That’s backwards.

A propos de

Jean-Paul Lizotte (« Jaypee »)

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

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

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

Résultats de signature

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

Mon guide ("playbook")

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

Compétences de base

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

Rôles récents

Émyode | Certifié B Corp

7 ans 10 mois

Responsable de la pratique SecDevOps | CIOSO adjoint

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

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

Principales contributions : 

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