Showing posts with label CultureDevOps. Show all posts
Showing posts with label CultureDevOps. Show all posts

Monday, September 8, 2025

Où ne pas automatiser : préserver la valeur humaine au cœur du SecDevOps

Le contact client: toujours humain en premier

On parle beaucoup d'automatisation dans le SecDevOps, et à juste titre. Elle permet d'aller plus vite, de réduire les erreurs et d'intégrer la sécurité à toutes les étapes du cycle de livraison. Mais nous avons aussi appris qu'il y a des limites. Certaines situations exigent la présence humaine, car la confiance, le jugement et la relation ne peuvent pas être programmés.

Voici quelques exemples où l'automatisation doit céder la place aux personnes.



C'est le point le plus essentiel. Lorsqu'un client subit une panne, un incident de sécurité ou un non-respect d'engagement de service, la communication doit être humaine. Bien sûr, les notifications automatiques sont utiles pour informer rapidement et parfois donner un premier aperçu. Mais ce message initial doit être identifié clairement comme automatisé.

La vraie valeur réside dans la suite. Les clients veulent savoir qu'une personne réelle a reconnu le problème, en comprend les impacts et s'engage à prendre des mesures concrètes. Trop d'automatisation dans ce domaine donne l'impression aux clients qu'ils ne sont qu'une donnée de plus dans un journal système. Ce n'est pas l'expérience que nous voulons offrir.

Les moments de responsabilité

Dans le SecDevOps, les échecs arrivent. Un déploiement peut mal tourner, une faille de sécurité peut passer inaperçue, ou un service peut tomber. Automatiser les alertes est utile, mais la responsabilité doit rester humaine.

Un message automatique peut dire "Service X est indisponible", mais seule une personne peut dire "Nous sommes désolés, nous comprenons ce que cela implique pour vous et voici nos prochaines actions". C'est ce passage de l'événement technique à l'engagement humain qui crée la confiance.

Les décisions à risque

Autre frontière claire: les décisions à fort enjeu. L'automatisation est parfaite pour détecter les anomalies, identifier une dépendance vulnérable ou bloquer un déploiement non conforme. Mais la décision de passer outre ou non doit appartenir à une personne.

Le risque est toujours contextuel. L'automatisation ne peut pas évaluer pleinement les priorités business, l'impact client ou les considérations éthiques. Elle doit éclairer la décision, pas la prendre.

La culture et le feedback

La culture d'équipe ne s'automatise pas. Des outils peuvent collecter des données ou produire des synthèses, mais l'essentiel reste la discussion entre personnes.

Chez JPSoftWorks, nous avons constaté que lorsque les boucles de feedback sont trop automatisées, les conversations perdent en richesse. Les métriques sont importantes, mais elles ne remplacent pas le dialogue.

L'éthique et la conformité

L'automatisation est précieuse pour collecter des preuves et vérifier la configuration des systèmes. Mais en cas de suspicion de non-conformité ou de dilemme éthique, c'est aux personnes d'évaluer et d'agir. La confiance repose autant sur le respect des règles que sur la capacité à démontrer du jugement et de la responsabilité.

Tracer la limite

Notre philosophie chez JPSoftWorks est claire: automatiser pour aller plus vite, mais jamais au détriment de la confiance. Dès qu'il est question d'empathie, de jugement ou de responsabilité, c'est aux humains d'entrer en scène.

C'est pourquoi nous combinons une automatisation puissante avec une approche résolument humaine. Nous libérons le temps des équipes grâce aux outils, afin que, lorsque la voix humaine compte vraiment, nous soyons présents.

Monday, June 9, 2025

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.


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...