Agile, DevOps et DevSecOps: un système, pas une échelle de maturité

Introduction

Après quelques années à accompagner des organisations "très matures": du moins sur les slides: on finit par reconnaître le scénario assez vite. Les équipes font de l'Agile. Les pipelines DevOps roulent. Les audits passent… jusqu'au jour où tout coince en même temps.

Une mise en production urgente. Un risque sécurité mal compris. Un comité qui s'invite dans un sprint. Et soudain, tout le monde se demande: mais pourtant, on fait Agile, non?

Chez JPSoftWorks, on a vu ça, assez souvent. Trop souvent. Et à chaque fois, le problème n'était pas Agile. Ni DevOps. Ni DevSecOps. Le vrai problème, c'était de les avoir traités comme des solutions concurrentes, au lieu de capacités complémentaires dans un même système.

Agile: apprendre et décider quand on ne sait pas tout

Agile, à la base, ce n'est pas une méthode de livraison. C'est un cadre pour prendre de meilleures décisions dans l'incertitude.

Quand ça fonctionne bien, Agile permet aux équipes de:

• Explorer des problèmes complexes sans prétendre tout savoir d'avance
• Ajuster les priorités à partir du feedback réel
• Rendre visibles les arbitrages, pas juste les tâches

C'est puissant. Mais il y a une limite structurelle qu'on rencontre souvent sur le terrain.

Dans beaucoup d'organisations, Agile s'arrête au "fait". Une fois le code mergé, la réalité opérationnelle commence ailleurs. Et ce "ailleurs" n'est pas toujours aligné avec les décisions prises en sprint.

Résultat:

• Des équipes qui livrent vite… mais déploient lentement
• La sécurité qui arrive tard, souvent sous forme d'exception
• Des incidents de prod vécus comme des surprises, voire des injustices

Ce n'est pas un problème de discipline des équipes mais plutôt un problème de conception du système.

DevOps: rendre le flux soutenable dans la vraie vie

DevOps est né précisément de cette fracture. Il pose une question plus large: est-ce que notre organisation est capable de faire passer du changement en continu, sans s'épuiser ni casser la production?

DevOps apporte des réponses concrètes:

• Des pipelines CI/CD automatisés
• Des environnements reproductibles via l'infrastructure as code
• Une responsabilité partagée vis-à-vis de la production
• Du feedback opérationnel qui retourne vers l'ingénierie

Quand c'est bien fait, la livraison devient un système prévisible, pas une suite d'exploits.

Mais là aussi, on voit des dérives.

Quand DevOps est abordé uniquement par les outils:

• Le fameux "you build it, you run it" devient du you build it, you suffer it
• Les pipelines vont vite, mais personne ne sait vraiment ce qu'ils garantissent
• La fiabilité repose sur des individus fatigués, pas sur des mécanismes

DevOps améliore le flux. Mais il ne définit pas, à lui seul, ce qui est acceptable en termes de risque. Et c'est là que la sécurité et la gouvernance doivent entrer en jeu: dès la conception.

DevSecOps / SecDevOps: concevoir la confiance, pas la bloquer

À l'échelle de l'entreprise, la sécurité n'est pas un contrôle final. C'est une propriété du système.

DevSecOps: ou SecDevOps, selon l'angle qu'on veut mettre: existe pour répondre à une question simple et inconfortable: est-ce qu'on peut démontrer, en continu, que ce qu'on livre est digne de confiance?

Concrètement, ça veut dire:

• Parler de menaces et de risques dès le raffinement du backlog
• Intégrer les politiques de sécurité directement dans les pipelines
• Automatiser les contrôles plutôt que multiplier les validations manuelles
• Générer des preuves par le fonctionnement normal du système

L'anti‑pattern, on le connaît bien: plus de scanners, plus de tableaux de bord, et toujours les mêmes surprises en fin de parcours. Ça, ce n'est pas du DevSecOps. C'est du bruit.

Un bon DevSecOps réduit la friction parce qu'il remplace les discussions subjectives par des règles testables.

La gouvernance: qu'on le veuille ou non, elle est déjà là

Soyons honnêtes: la gouvernance existe toujours. La seule question est de savoir où elle vit.

Quand elle n'est pas conçue explicitement, elle apparaît sous forme de:

• Réunions d'urgence
• Approbations informelles
• Fichiers Excel de suivi de risque
• Gens qui disent non, parce qu'ils n'ont aucun moyen sûr de dire oui

Chez JPSoftWorks, on traite la gouvernance comme une contrainte de conception, pas comme une taxe organisationnelle.

Ça donne des choses très concrètes:

• Séparation des rôles implémentée par le code
• Promotions d'environnements basées sur des critères mesurables
• Artéfacts de conformité générés automatiquement par les pipelines

Résultat? Moins de friction. Moins d'ambiguïté. Et paradoxalement, plus de vitesse.

À quoi ça ressemble, concrètement, de bout en bout

Un flux réaliste, pas idéalisé:

Raffinement du backlog
On documente les hypothèses de risque en même temps que les critères d'acceptation.

Pipeline CI/CD
Code applicatif, infrastructure et politiques évoluent ensemble, versionnés au même endroit.

Garde-fous automatisés
Les contrôles échouent tôt, avec du feedback exploitable, pas des alertes vagues.

Observabilité
Ce qui se passe en production alimente les décisions futures. Pas les blâmes.

Ça demande de nouvelles habitudes:

• Écrire des politiques comme des tests
• Traiter les pipelines comme des produits
• Collaborer plus tôt que ce qui est confortable

Le défi n'est pas technique. Il est systémique.

Ce que ça change vraiment, côté culture

Quand le système est bien conçu, quelque chose d'intéressant se produit.

Les discussions changent de ton.
On débat des faits, pas des intentions.
La sécurité devient prévisible.
La responsabilité devient structurelle, pas personnelle.

Et oui, les gens respirent un peu mieux.

La culture ne précède pas la structure. Elle en découle.

Conclusion

Agile, DevOps et DevSecOps ne sont pas des étapes de maturité. On ne "passe" pas de l'un à l'autre.

Ce sont des capacités complémentaires qu'il faut concevoir ensemble, sous de vraies contraintes: humaines, techniques et réglementaires.

Les organisations qui s'en sortent le mieux ne cherchent pas la bonne méthode. Elles conçoivent un système qui tient dans le temps.

Si ce récit vous semble familier: ou s'il met le doigt sur des irritants bien connus chez vous: partagez votre expérience en commentaire. Et si vous voulez explorer ce que ce genre de système pourrait donner dans votre réalité, on peut en parler chez JPSoftWorks. Sans dogme. Avec du concret. ;)