Vous avez déjà parcouru un rapport sur la maturité DevOps ou la qualité logicielle tout en vous disant : « Sympa, mais on se base sur quoi, au juste ? ». L’usage de référentiels (DORA, CALMS, OWASP SAMM, ISO 25010, 12-factor app, etc.) gagnerait du terrain dans les équipes de développement. Pourquoi ? Parce qu’on veut objectiver les pratiques, se comparer à des standards et s’améliorer. Pour autant, il n’y a pas de framework miracle ni de baguette magique, chacun a ses atouts, ses limites. Mieux vaut donc tous les connaître pour savoir où mettre le curseur, et surtout comment les combiner ou les adapter.
DORA, CALMS, OWASP SAMM, ISO 25010, 12-factor app…
Avant d’aller plus loin, petit rappel sur les principaux frameworks dont on a souhaité vous parler ici :
- DORA (DevOps Research and Assessment) : popularisé par Google Cloud, axé sur la performance logicielle (temps de déploiement, fréquence, MTTR…).
- CALMS (Culture, Automation, Lean, Measurement, Sharing) : permet d’évaluer la maturité DevOps d’une orga.
- OWASP SAMM : s’attache aux pratiques de sécurité dans le cycle de dev. SAMM = Software Assurance Maturity Model.
- ISO 25010 : normalise la qualité logicielle, en listant les caractéristiques (sécurité, fiabilité, maintenabilité, etc.).
- 12-factor app : un guide plus « cloud native » sur la façon de concevoir une appli (config, logs, dépendances, etc.).
On pourrait en citer d’autres (CMMI, par exemple), mais déjà, ces six-là couvrent déjà un spectre relativement large.
À quoi sert un cadre d’audit ?
Pour faire simple, un framework d’audit n’est absolument pas un but en soi. Il s’agit d’un outil de mesure qui sert à :
- Identifier vos forces et faiblesses : on coche une liste de pratiques, on repère si on est au top ou si on bricole encore sur les tests automatiques, la config, etc.
- Donner un langage commun : plus besoin de jargonner. On dit : « Selon DORA, on est sur un temps de remise en service de 2 jours. Il faut viser 2 heures. »
- Faciliter la comparaison : se situer par rapport à d’autres équipes, ou par rapport à un idéal. Indispensable si on veut motiver la direction : « Regardez, on est au niveau 2 de SAMM, on vise le 3 d’ici la fin de l’année. »
Le piège ? Croire qu’on doit appliquer le framework au pied de la lettre.
N’oubliez pas qu’un référentiel reste un canevas, pas un dogme.
Points forts et limites de chaque référentiel
Envie de vous y retrouver ? Petit tour rapide des caractéristiques, en toute franchise :
- DORA : super clair pour évaluer la cadence de déploiement, la fiabilité des releases, etc. En revanche, ça survole la partie sécu ou architecture profonde.
- CALMS : vise la culture, l’état d’esprit DevOps, l’automatisation, la collaboration, etc. Mais ça reste parfois conceptuel. Il faut donner du concret derrière chaque lettre (Culture, Automation, Lean, Measurement, Sharing).
- OWASP SAMM : efficace pour cartographier la sécurité dans le cycle de vie logicielle (du design à la maintenance). Par contre, pas un mot sur la rapidité de déploiement ou la collaboration inter-équipes. C’est de la sécu, point.
- ISO 25010 : propose un modèle très détaillé de la qualité logicielle (maintenabilité, compatibilité, efficacité, etc.). Sérieux, complet, mais parfois jugé trop académique ou exigeant en doc.
- 12-factor app : plus pratique et orienté cloud, il est focalisé sur le design d’une appli web. Décrit de bonnes pratiques en termes de logs, config, dépendances… Utile, mais ne couvre pas la totalité d’un cycle dev (pas de focus sécu, devops culture, etc.).
Ce que ça montre ? Aucun ne fait tout.
DORA est top pour la performance devops, ISO 25010 pour la qualité au sens large, SAMM pour la sécu, etc. A vous de piocher selon vos priorités, et/ou de combiner.
Pourquoi il faut adapter à son contexte ?
Parce qu’encore une fois, un framework n’est jamais une solution universelle…
Adopter DORA si on fait des releases mensuelles de gestion de paie critique, ça a du sens (on vise la fiabilité, la rapidité de déploiement, etc.). Mais si on fait de la micro-appli SaaS BtoC, on pourrait préférer la logique 12-factor pour être super cloud-native.
Pareil, si on est dans un environnement ultra-sensible, on glisse vers OWASP SAMM ou un gros accent sur la sécu. Si au contraire, on a un besoin de standardiser la “qualité logicielle” transversale, ISO 25010 nous guide.
Côté culture, si l’entreprise est encore très silo, passer direct sur CALMS (qui encourage la collaboration extrême) peut être un choc ! Mieux vaut y aller graduellement, en définissant des jalons. Inutile de se saborder en imposant un framework abstrait auquel personne n’adhère.
L’intérêt de passer par un tiers expérimenté pour croiser les approches
Si la démarche peut paraître simple (on télécharge un livre blanc DORA, une review 12-factor, et en avant Guingamp), s’auto-évaluer de manière objective reste délicat. On a toujours tendance à se sur (ou sous) évaluer.
Un tiers expérimenté (cabinet ou consultant) apporte du recul : il va analyser les process, interroger les devs, la QA, le management, et dresser un bilan clair.
Ensuite, il peut piocher dans chaque référentiel les éléments qui font sens, plutôt que de brandir un framework unique comme la vérité absolue. On obtient alors un audit multi-critères : un peu de DORA sur le pipeline CI/CD, un soupçon de 12-factor pour la structure d’app, du SAMM pour la sécu. Bref, un cocktail sur mesure, tout à fait pertinent.
Si vous souhaitez aller plus loin sur ce sujet, des sociétés de conseil et ESN proposent des audits sur mesure ou packagée comme Octo, Zenika, Inside, Theodo…