Showing posts with label ContinuousLearning. Show all posts
Showing posts with label ContinuousLearning. Show all posts

Tuesday, June 3, 2025

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

  1. Invite security to the daily stand-up. Today. Zero slide decks required.
  2. Automate one pain-point. 
  3. Add one security gate: OwaspSAST, SCA or container scan, before the next sprint review.
  4. 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.

Monday, June 2, 2025

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 terrainQuoi faire
Vous avez déjà un CI/CDGreffez 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 surchargeAutomatisez 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)

FluxSécuritéCulture
Gestion du changementMTTR-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 autoNb de « kudos » pour détection de risque précoce
Points d’histoire livrésNouvelles mesures de sécurité mises en placeAmé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.

Friday, May 16, 2025

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)

Une peinture d'une personne poussant une structure en bois


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

TechnologyInitial FearWhat 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

ConcernPractical 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

Théâtre de la sécurité infonuagique: pourquoi les "meilleures pratiques" d'Azure ne vous sécurisent pas réellement (Avec blogueur invité Joshua Copeland)

Seule, une "checklist" ne vaut rien. Joshua Copeland et Jean-Paul Lizotte Image générée par l'IA. Tout le monde aime...