12.4
12.4 Auto-évaluation de maturité
Chaque chapitre de ce guide se termine par un « modèle de maturité » qui décrit comment une pratique évolue typiquement. Cette annexe consolide le modèle de maturité de chaque chapitre en une seule référence, pour que vous puissiez évaluer une équipe, un domaine, ou une organisation entière d’un coup d’œil.
L’échelle commune à cinq niveaux
Tous les chapitres décrivent la même progression. La formulation exacte varie légèrement d’un chapitre à l’autre, mais l’intention se cartographie proprement sur ces cinq niveaux :
- Niveau 1, Initier. Ad hoc, réactif, et dépendant des personnalités. Les pratiques n’existent que là où un individu les choisit, si bien que les résultats dépendent de l’héroïsme et de la chance.
- Niveau 2, Développer. Des pratiques de base existent, mais elles sont incohérentes entre les équipes, partiellement manuelles, et souvent contournées sous pression.
- Niveau 3, Standardiser. Les pratiques sont documentées, standardisées, et appliquées à l’échelle de l’organisation. C’est le plancher d’audit et de conformité : le niveau que la plupart du travail en grande entreprise et en gouvernement doit atteindre pour être fiable et auditable.
- Niveau 4, Gérer. Les pratiques sont mesurées et contrôlées avec des données et des indicateurs par rapport à des lignes de base. Vous savez quantitativement comment chaque pratique performe, et vous agissez sur les chiffres.
- Niveau 5, Orchestrer. Les pratiques sont continuellement améliorées, intégrées à travers l’organisation, et adaptatives. Le chemin sûr ou correct est le défaut, et l’organisation apprend et évolue délibérément.
Comment l’utiliser pour l’auto-évaluation
- Pour chaque chapitre pertinent à votre contexte, lisez les cinq cellules ci-dessous et choisissez le niveau qui décrit honnêtement votre comportement typique, pas votre meilleure équipe dans son meilleur jour, et pas votre politique écrite, mais ce qui se passe réellement.
- Notez chaque chapitre de 1 à 5. Arrondissez vers le bas en cas de doute ; une pratique incohérente est de niveau 2, pas de niveau 3.
- Faites la moyenne des scores au sein d’une partie pour voir où se situe tout un domaine, puis regardez la dispersion : une partie à « 3 en moyenne » qui cache un chapitre de niveau 1 porte quand même un risque de niveau 1.
- Réévaluez périodiquement et suivez la tendance. Le mouvement compte plus que n’importe quel instantané isolé.
La maturité est un moyen, pas une fin
Une maturité plus élevée n’est pas automatiquement meilleure. L’objectif est l’adéquation : assez de rigueur pour gérer le risque et l’échelle que vous affrontez réellement, et pas plus. Un outil petit et à faible enjeu n’a pas besoin d’ingénierie du chaos de niveau 5. Viser un niveau élevé comme un trophée, plutôt que pour résoudre un problème réel, produit de la cérémonie sans valeur. Lisez chaque « niveau 5 » ci-dessous comme « approprié quand les enjeux le justifient », et laissez le risque, l’échelle, et l’exposition réglementaire décider jusqu’où grimper.
Partie 1. Personnes
| Sujet | Niveau 1 Initier | Niveau 2 Développer | Niveau 3 Standardiser | Niveau 4 Gérer | Niveau 5 Orchestrer |
|---|---|---|---|---|---|
| Culture et valeurs d’ingénierie | La culture est accidentelle et dépendante des personnalités ; les incidents signifient le blâme ; le savoir vit dans quelques têtes. | Certaines équipes tiennent des post-mortems et écrivent des documents, mais la pratique est incohérente et non renforcée par le leadership. | L’apprentissage sans blâme, les modèles de responsabilité, et une culture de l’écrit sont des normes à l’échelle de l’organisation avec des attentes et des outils clairs. | La santé culturelle est mesurée (enquêtes de sécurité psychologique, taux d’apprentissage des incidents, rétention) et suivie par rapport à des lignes de base et actionnée. | La culture est continuellement améliorée et les pratiques se propagent entre les équipes ; le leadership adapte les normes à mesure que l’organisation grandit et apprend. |
| Topologies d’équipe | Les équipes se forment par accident ou par effectif ; la structure reflète la hiérarchie héritée ; les dépendances sont partout. | Certaines équipes alignées sur les flux existent, mais des goulots d’étranglement partagés et des silos fonctionnels persistent. | Les quatre types d’équipe et les modes d’interaction explicites sont utilisés délibérément ; les plateformes et l’InnerSource réduisent les dépendances. | La charge cognitive, le flux, et les comptes de dépendances sont mesurés par équipe par rapport à des cibles ; les frontières sont ajustées quand les chiffres glissent. | L’organisation remodèle continuellement les équipes et les modes d’interaction pour maintenir le flux à mesure que les produits et plateformes évoluent. |
| Rôles, échelles de carrière, croissance | Aucune échelle écrite ; les promotions et la rémunération sont ad hoc et dépendantes des personnalités. | Une échelle de base existe mais est appliquée de façon incohérente ; pas de calibration ; le recrutement n’est pas structuré. | Des filières duales, une matrice de compétences claire, la calibration, et un recrutement structuré sont la norme. | Les taux de progression, l’équité salariale, et le temps passé à un niveau sont mesurés par rapport à des lignes de base ; les résultats de calibration sont analysés pour les biais. | Le cadre évolue continuellement avec le travail ; le parrainage et l’apprentissage sont délibérés et à l’échelle de l’organisation à mesure que les rôles changent. |
| Façons de travailler | Le processus est ad hoc ou du culte du cargo ; la communication est pilotée par les réunions et non documentée ; les estimations sont traitées comme des promesses. | Une méthodologie est suivie de façon cohérente, mais les cérémonies sont mécaniques et la coordination inter-équipes est lourde. | Les pratiques sont choisies pour s’adapter au contexte ; la communication asynchrone et axée sur les documents est la norme ; l’estimation informe, ne contrôle pas. | Les indicateurs de flux (délai, travail en cours, débit) sont suivis par rapport à des lignes de base et revus à chaque cycle. | Les équipes ajustent continuellement leur façon de travailler à partir de ces indicateurs ; le besoin de coordination est minimisé à la source et les bonnes pratiques se propagent à l’échelle de l’organisation. |
| Prise de décision et gouvernance | Les décisions sont ad hoc et non enregistrées ; la gouvernance est absente ou un goulot d’étranglement général ; la dette est invisible. | Certaines décisions sont documentées et une certaine revue existe, mais le processus est incohérent et mal adapté au poids de la décision. | Les ADR, une voie balisée, la délégation basée sur la réversibilité, et un inventaire de dette sont standard et transparents. | Le temps de cycle de décision, les taux d’annulation, et les niveaux de dette sont mesurés ; l’examen est calibré selon le poids de la décision par rapport à ces chiffres. | La gouvernance est continuellement ajustée à travers l’organisation ; l’examen cible les décisions irréversibles ; la dette et l’approvisionnement sont gérés comme des portefeuilles évolutifs. |
Partie 2. Programmation logicielle
| Sujet | Niveau 1 Initier | Niveau 2 Développer | Niveau 3 Standardiser | Niveau 4 Gérer | Niveau 5 Orchestrer |
|---|---|---|---|---|---|
| Normes de codage et style | Le style est propre à chaque auteur ; pas de configurations partagées ; le formatage est débattu en revue. | Chaque équipe a un formateur et un linter, mais les configurations et règles varient entre équipes. | Des configurations centrales partagées par langage ; application en CI ; les nouveaux dépôts héritent des normes via des modèles. | L’adoption des normes, les taux de violation, et l’impact sur le temps de revue sont mesurés par rapport à des lignes de base ; les configurations sont versionnées et gouvernées. | Les normes sont continuellement affinées à partir de ces données et partagées à l’échelle de l’organisation ; l’application est presque sans friction et s’adapte aux nouveaux langages. |
| Principes de conception logicielle | La conception est ad hoc ; le couplage s’accumule ; les principes sont inconnus ou invoqués comme des slogans. | Les équipes connaissent les principes et les appliquent, mais de façon incohérente et souvent dogmatique. | Un vocabulaire de conception partagé, une analyse délibérée du couplage et de la cohésion, et des contextes bornés alignés sur les équipes. | Le couplage, la cohésion, et les indicateurs de taux d’échec des changements informent les revues de conception par rapport à des lignes de base ; les décisions sont enregistrées. | Les décisions de conception sont revisitées à mesure que les preuves s’accumulent ; les principes sont appliqués avec nuance et les choix de paradigme s’adaptent à l’échelle de l’organisation à mesure que le domaine évolue. |
| API et conception d’interfaces | Les API émergent de l’implémentation ; pas de conventions partagées ; les changements cassants sont fréquents et non annoncés. | Les équipes suivent des conventions REST de base et versionnent de façon informelle, mais la cohérence et la documentation varient. | Une conception contract-first, des spécifications lisibles par machine, une politique de dépréciation, et des conventions d’erreur et de pagination cohérentes. | L’adoption, la latence, les taux d’erreur, et la fréquence des changements cassants sont mesurés par API par rapport à des cibles. | Les API sont des produits gouvernés dans un catalogue avec une forte expérience développeur ; la pratique s’adapte continuellement et les ruptures sont rares et bien gérées à l’échelle de l’organisation. |
| Stratégie de test | Le test est manuel et ad hoc ; la couverture automatisée est minimale ; les régressions sont fréquentes. | Des tests unitaires et d’intégration automatisés existent, mais la suite est lente ou instable et la confiance est faible. | Une suite équilibrée, rapide, fiable bloque chaque changement ; l’instabilité est gérée ; le test non fonctionnel est intégré. | La couverture, l’instabilité, les défauts échappés, et la durée de la suite sont suivis par rapport à des lignes de base pour cibler l’effort. | Des techniques avancées (basées sur les propriétés, mutation, fuzzing) ciblent le code à haute valeur ; la stratégie s’améliore continuellement et se propage entre équipes. |
| Revue de code et collaboration | La revue est incohérente ou sautée ; les problèmes mécaniques dominent ; les normes de retour ne sont pas fixées. | La revue est obligatoire mais lente et variable ; l’automatisation est partielle ; la taille et la qualité des PR varient largement. | Des PR petites, des vérifications mécaniques automatisées, des normes et des retours clairs, et une latence surveillée. | La latence de revue, la taille des PR, et les taux d’échappement de défauts sont suivis par rapport à des cibles ; la profondeur est adaptée au risque mesuré. | L’organisation améliore continuellement la revue à partir de ces données ; le pair programming et l’assistance par IA sont adoptés délibérément et les pratiques se propagent entre équipes. |
| Contrôle de version et gestion des sources | Branchement ad hoc ; branches à longue durée de vie ; messages pauvres ; pas de détection de secrets ; douleur fréquente de fusion. | Un modèle de branchement et des conventions de message cohérents existent, mais les branches vivent trop longtemps et l’application est partielle. | Développement basé sur le tronc, ligne principale protégée, conventions de commit appliquées, détection de secrets, structure de dépôt délibérée. | La durée de vie des branches, la fréquence de fusion, et les taux de retour arrière sont mesurés par rapport aux indicateurs de livraison et aux lignes de base. | L’automatisation applique l’hygiène de bout en bout ; la structure des dépôts et le flux de travail évoluent continuellement à travers l’organisation à mesure que les besoins de livraison changent. |
| Documentation | La documentation est éparse, dispersée, et périmée ; le savoir vit dans les têtes des gens. | Des documents clés existent (READMEs, quelques livres d’exécution) mais sont maintenus de façon incohérente et difficiles à trouver. | Documentation-as-code avec une structure claire, documentation d’API et journal des modifications générés, enregistrements de décision, et attentes de mise à jour. | La couverture, la fraîcheur, et l’exactitude de la documentation sont mesurées par rapport à des lignes de base ; l’obsolescence est signalée automatiquement. | La documentation est vivante, largement générée ou testée par rapport au système, possédée et découvrable ; la pratique s’améliore continuellement à l’échelle de l’organisation. |
Partie 3. Systèmes
| Sujet | Niveau 1 Initier | Niveau 2 Développer | Niveau 3 Standardiser | Niveau 4 Gérer | Niveau 5 Orchestrer |
|---|---|---|---|---|---|
| Fondamentaux de l’architecture | L’architecture est implicite et vit dans les têtes ; pas d’attributs de qualité ni d’ADR ; les décisions émergent pendant les incidents. | Des diagrammes clés existent et les décisions majeures sont parfois enregistrées ; les attributs de qualité sont nommés mais rarement quantifiés ; la documentation dérive. | Des scénarios d’attributs de qualité et des ASR sont spécifiés ; les ADR sont routiniers ; la documentation C4/arc42 est maintenue près du code ; des revues de compromis ont lieu. | Des fonctions de fitness appliquent les attributs de qualité en CI et enregistrent les résultats mesurés par rapport à des lignes de base ; les compromis sont quantifiés. | L’architecture évolue continuellement avec ces données à travers l’organisation ; la documentation reste assez fiable pour les auditeurs à mesure que le système s’adapte. |
| Styles et modèles architecturaux | Un monolithe emmêlé ou un fouillis distribué accidentel ; les frontières suivent les couches ou l’histoire ; le style est choisi par la mode. | Des frontières modulaires délibérées ou quelques services grossiers ; certaines préoccupations transversales sont cohérentes ; les scissions restent ad hoc. | Des services alignés sur des contextes bornés possédant leurs données ; une passerelle/BFF là où c’est approprié ; une stratification propre/hexagonale standard. | Les décisions de style sont fondées sur les preuves, utilisant des données mesurées de couplage, de latence, et de coût de changement par rapport à des lignes de base. | Une plateforme mature rend la distribution bon marché ; l’organisation reconsolide quand une scission cesse de rapporter et adapte le style à mesure que les preuves changent. |
| Systèmes distribués | Les appels distants sont traités comme locaux ; pas de nouvelle tentative ou naïve ; les échecs se propagent en cascade ; le débogage se fait journal par journal, machine par machine. | Les délais d’expiration et les nouvelles tentatives de base existent mais sont incohérents ; une certaine idempotence ; les journaux sont centralisés mais non corrélés. | Idempotence, recul exponentiel, disjoncteurs, cloisons via des bibliothèques partagées ; sagas ; traçage distribué ; cohérence documentée par flux. | La résilience est mesurée par rapport aux SLO ; les résultats d’injection de fautes et les taux d’échec sont suivis par rapport à des lignes de base. | La résilience est le défaut de la plateforme, continuellement testée par injection de fautes ; la dégradation gracieuse est conçue dès le départ et évolue à l’échelle de l’organisation. |
| Architecture et stockage des données | Une seule base de données pour tout usage ; pas de discipline de migration ; mise en cache accidentelle ; l’échelle se fait par une machine plus grosse. | Les choix de stockage sont majoritairement délibérés ; un cache et peut-être un entrepôt de données ; les migrations versionnées nécessitent parfois un arrêt. | Persistance polyglotte adaptée aux charges de travail, chaque magasin possédé ; migrations automatisées sans interruption ; mise en cache et répliques explicites. | Les choix de stockage sont mesurés par rapport aux modèles d’accès, à la latence, et aux lignes de base de coût ; les décisions de partitionnement et de mise en cache sont fondées sur les données. | L’architecture des données est continuellement revue et évoluée à travers l’organisation ; les migrations sont automatisées et auditées à mesure que les charges de travail changent. |
| Scalabilité, performance, résilience | Instance unique ou mise à l’échelle verticale ; état côté serveur ; pas de test de charge ni de budgets ; les échecs causent des pannes complètes. | Niveaux sans état mis à l’échelle horizontalement ; mise à l’échelle automatique de base ; certains tests de charge avant lancement ; reprise après sinistre documentée mais rarement testée. | Capacité planifiée avec marge ; budgets de performance en CI ; modèles de résilience standard ; RTO/RPO définis et reprise après sinistre testée. | La capacité est prévue à partir de la charge mesurée ; les budgets de performance et les RTO/RPO sont suivis par rapport à des lignes de base. | Basculement automatisé multi-régions, chaos continu, et journées de jeu prouvent et améliorent les objectifs de récupération à mesure que le système évolue à l’échelle de l’organisation. |
| Modernisation des systèmes hérités | Le système hérité est craint et gelé ; pas d’inventaire ; la modernisation est une réécriture totale ; le savoir vit dans des têtes qui partent à la retraite. | Un inventaire existe et un certain risque est compris ; le système hérité est enveloppé avec des API ; la pensée big-bang persiste ; la migration est sous-estimée. | Les systèmes sont priorisés par risque et valeur ; le motif de la figue étrangleuse et le branchement par abstraction sont standard ; la migration est réconciliée par exécution double. | La modernisation est gérée en portefeuille avec un risque, une valeur, et un progrès mesurés par rapport à des lignes de base. | La modernisation est continue à travers l’organisation ; le remplacement incrémental est routinier, réversible, et s’adapte à mesure que les priorités changent. |
Partie 4. Sécurité
| Sujet | Niveau 1 Initier | Niveau 2 Développer | Niveau 3 Standardiser | Niveau 4 Gérer | Niveau 5 Orchestrer |
|---|---|---|---|---|---|
| Fondamentaux et culture de sécurité | La sécurité est réactive et centralisée ; les revues sont tardives voire absentes ; pas de modélisation des menaces ; la sécurité est « le problème de quelqu’un d’autre ». | Une équipe de sécurité définit des normes ; une certaine modélisation des menaces sur les projets majeurs ; formation de base ; la sécurité est vue comme un portail. | Des champions de sécurité intégrés ; la modélisation des menaces est routinière ; un cycle de vie de développement sécurisé documenté ; priorisation fondée sur le risque ; revues sans blâme. | Les indicateurs de sécurité (couverture de modélisation des menaces, temps de correction, adoption des contrôles) sont suivis par rapport à des lignes de base. | La sécurité est véritablement l’affaire de tous ; la modélisation des menaces est habituelle ; la confiance zéro est largement réalisée et la pratique s’améliore continuellement à l’échelle de l’organisation. |
| Sécurité applicative | La sécurité dépend du savoir individuel ; pas de contrôles standard ; secrets dans le code ; dépendances périmées ; authentification ad hoc. | Sensibilisation au Top 10 OWASP ; certaines protections de framework ; un gestionnaire de secrets utilisé de façon inégale ; analyse de dépendances occasionnelle. | Exigences basées sur l’ASVS par niveau ; requêtes paramétrées ; identité centrale avec MFA ; secrets gérés ; SBOM et analyse de pipeline. | La densité de vulnérabilités, le temps moyen de correction, et la couverture des contrôles sont mesurés par rapport à des lignes de base à travers les services. | Les défauts sécurisés sont livrés dans des frameworks de voie balisée ; les identifiants de courte durée et l’assurance complète de la chaîne d’approvisionnement (SLSA) sont vérifiés en continu à l’échelle de l’organisation. |
| Sécurité de l’infrastructure et du cloud | Provisionnement manuel ; permissions larges et clés statiques ; réseaux plats ; chiffrement incohérent ; pas de gestion de posture. | Quelques rôles IAM et MFA ; niveaux réseau de base ; chiffrement au repos pour les magasins majeurs ; revues manuelles périodiques ; IaC partielle. | RBAC/ABAC à privilège minimal avec identifiants de courte durée ; segmentation par défaut refusée ; chiffrement par défaut avec KMS ; CSPM avec politique. | La posture, la dérive, et les indicateurs de violation de politique sont suivis par rapport à des lignes de base ; l’efficacité des garde-fous est mesurée. | Les défauts sécurisés sont livrés dans les zones d’atterrissage et l’IaC ; la micro-segmentation et les garde-fous préventifs évoluent continuellement et la dérive est auto-corrigée à l’échelle de l’organisation. |
| Opérations de sécurité | Le test de sécurité est manuel et rare ; pas de journalisation centrale ni de SIEM ; pas de plan d’incident ; correctifs ad hoc ; jamais testé de façon adversariale. | Quelques scanners dans le pipeline ; journalisation centrale ; un plan d’incident de base ; délais de correctifs relâchés ; test d’intrusion annuel. | Analyse DevSecOps complète avec portails basés sur le risque ; SIEM avec un peu de SOAR ; réponse aux incidents répétée avec exercices sur table ; SLA de remédiation ; équipe rouge. | Le MTTD et le MTTR sont mesurés par rapport à des lignes de base ; la couverture de détection est cartographiée sur les techniques adverses et suivie. | Le test et la réponse sont hautement automatisés ; l’équipe violette et l’ingénierie de détection s’améliorent continuellement et s’adaptent aux nouvelles menaces à l’échelle de l’organisation. |
| Vie privée et protection des données | Les données personnelles sont collectées librement ; pas d’inventaire, de minimisation, ni de conservation ; le consentement est une réflexion après coup ; pas de processus de droits. | Une politique de confidentialité et un consentement de base existent ; une certaine sensibilisation à la conservation ; les demandes de droits sont traitées manuellement et lentement. | Vie privée dès la conception avec des AIPD ; les données sont cartographiées et classifiées ; la conservation est appliquée ; la base légale est documentée ; les droits sont satisfaits dans les délais. | La posture de confidentialité est mesurée : couverture de l’inventaire de données, conformité de conservation, et délai de traitement des demandes de droits par rapport à des lignes de base. | La vie privée est une contrainte d’ingénierie par défaut ; la minimisation et la conservation automatisée sont standard ; les demandes de droits sont en libre-service et la pratique s’adapte à l’échelle de l’organisation. |
| Conformité et gouvernance | La conformité est réactive ; pas de cadre de contrôle ; les preuves sont assemblées manuellement sous délai ; constats fréquents. | Les cadres clés sont identifiés ; certains contrôles documentés ; les audits passent mais avec un effort manuel lourd ; l’accessibilité est considérée tardivement. | Un cadre de contrôle unifié fait correspondre les normes entre elles ; les preuves sont partiellement automatisées ; l’accessibilité est testée ; les registres et autorisations sont établis. | L’efficacité des contrôles et la couverture des preuves sont mesurées en continu par rapport à des lignes de base ; les constats sont suivis dans le temps. | La conformité est continue avec des preuves toujours actives et la conformité en tant que code ; les nouvelles certifications sont à faible coût et le cadre s’adapte à l’échelle de l’organisation, prêt pour l’audit à tout moment. |
Partie 5. Conception UI/UX
| Sujet | Niveau 1 Initier | Niveau 2 Développer | Niveau 3 Standardiser | Niveau 4 Gérer | Niveau 5 Orchestrer |
|---|---|---|---|---|---|
| Fondamentaux UX | Pas de pratique UX dédiée ; les décisions se prennent par opinion ; la recherche est ad hoc ; flux et terminologie incohérents. | Quelques concepteurs et des tests d’utilisabilité occasionnels ; les personas ne sont pas maintenus ; l’UX est une phase, souvent contournée. | La recherche à méthodes mixtes continue alimente la priorisation ; personas, parcours, et architecture de l’information partagés ; portails de qualité UX dans la définition du terminé. | Les indicateurs UX (réussite des tâches, satisfaction, scores d’utilisabilité) sont suivis par rapport à des lignes de base aux côtés des indicateurs métier. | La recherche est continue et liée aux résultats ; des expériences contrôlées bouclent la boucle et les enseignements se propagent entre équipes à mesure que les produits évoluent. |
| Conception UI et systèmes de conception | Chaque équipe construit sa propre interface ; pas de composants partagés ; apparence incohérente ; couleurs et espacements codés en dur. | Un guide de style partiel ou une bibliothèque de composants existe mais est optionnel et souvent désynchronisé entre la conception et le code. | Un système de conception à jetons avec une bibliothèque codée maintenue, une documentation, et une gouvernance est utilisé à travers les équipes ; l’accessibilité est intégrée. | La parité conception-code, l’adoption des composants, et la dérive sont mesurées par rapport à des lignes de base ; le versionnage est suivi. | Le système est un produit gouverné avec une feuille de route ; il s’améliore continuellement à l’échelle de l’organisation et les changements de marque deviennent des changements de jetons. |
| Accessibilité | Pas de pratique d’accessibilité ; les problèmes sont trouvés par plainte ou poursuite ; balisage non sémantique et non testé. | La sensibilisation existe ; une certaine analyse automatisée et un audit avant lancement ; l’accessibilité est une liste de contrôle tardive, souvent déprioritisée. | Le WCAG 2.2 AA est la norme ; l’accessibilité est intégrée au système de conception, testée, et dans la définition du terminé ; les équipes sont formées avec un propriétaire. | La conformité d’accessibilité est mesurée en CI par rapport aux lignes de base WCAG ; les taux de défauts et les résultats d’audit sont suivis. | L’accessibilité est continue ; les personnes handicapées sont impliquées dans la recherche ; elle est intégrée dans l’approvisionnement, les jetons, et la CI et s’améliore à l’échelle de l’organisation. |
| Conception de contenu et communication | Pas de pratique de contenu ; les mots sont écrits ad hoc ; terminologie et ton incohérents ; erreurs et états vides inutiles. | Un guide de style peut exister ; une certaine sensibilisation au langage clair ; le contenu reste tardif et par équipe avec peu de réutilisation. | Une stratégie de contenu, un guide de voix et de ton, et un glossaire utilisés à travers les équipes ; le langage clair est standard ; des motifs partagés. | Le contenu est mesuré par rapport aux résultats (compréhension, achèvement des tâches, taux d’erreur) par rapport à des lignes de base. | Le contenu s’améliore continuellement à partir de ces preuves ; les modèles sombres sont interdits et audités ; les motifs sont localisés et accessibles par défaut à l’échelle de l’organisation. |
| Internationalisation et localisation | Langue unique ; chaînes codées en dur ; hypothèses non Unicode ; les nouvelles locales nécessitent des changements de code. | Les chaînes sont externalisées et Unicode est utilisé, mais la localisation est un lot manuel avant lancement ; formatage et pluriels incohérents. | Architecture i18n partagée et formatage sensible à la locale ; un système de gestion de traduction et un pipeline continu ; pseudo-localisation et CI multi-locale. | La couverture de localisation, la fraîcheur des chaînes, et les taux de défauts par locale sont mesurés par rapport à des lignes de base. | L’i18n est imposée par l’outillage et le linting à travers les équipes ; la localisation est continue, l’adaptation culturelle est systématique, et les nouvelles locales se lancent rapidement. |
| Ingénierie frontend | Frontend ad hoc par équipe ; code client lourd ; pas de budgets ; testé uniquement sur les appareils de l’équipe ; le framework choisi par la mode. | Certains outils partagés et une bibliothèque de composants ; la performance est mesurée occasionnellement, pas budgétée ; test inter-appareils limité. | Le framework et le rendu sont choisis délibérément par surface ; les budgets sont appliqués en CI avec des données utilisateur réelles ; l’amélioration progressive est standard. | La performance, la résilience, et la portée sont mesurées par rapport à des lignes de base utilisateur réelles et des budgets ; les régressions font échouer la construction. | Ces signaux sont liés aux résultats et continuellement améliorés à travers les surfaces à mesure que le frontend et ses utilisateurs évoluent. |
Partie 6. Intelligence artificielle
| Sujet | Niveau 1 Initier | Niveau 2 Développer | Niveau 3 Standardiser | Niveau 4 Gérer | Niveau 5 Orchestrer |
|---|---|---|---|---|---|
| Stratégie et préparation à l’IA | Expérimentations ad hoc ; pas de stratégie partagée ; décisions pilotées par le battage médiatique et l’enthousiasme individuel. | Cadrage du problème sur certains projets ; une première référence de plateforme ; le choix construire-versus-acheter est discuté mais incohérent. | Un portefeuille de cas d’usage avec des indicateurs clairs, un arbre de décision, des évaluations de préparation, et une analyse de dépendance/coût total de possession. | La valeur des cas d’usage, l’adoption, et la préparation sont mesurées par rapport à des lignes de base ; le retour sur investissement du portefeuille est suivi. | La stratégie IA est intégrée à la planification métier et de risque ; la préparation est maintenue en continu et les systèmes sont recalibrés sur les preuves à l’échelle de l’organisation. |
| MLOps | Modèles construits ad hoc dans des carnets ; déploiement manuel ; pas de versionnage des données ou des modèles ; pas de surveillance. | Un certain suivi d’expériences et un registre de modèles ; déploiement semi-automatisé ; surveillance de base pour quelques modèles. | Plateforme partagée avec magasin de caractéristiques, registre, pipelines reproductibles, traçabilité ; surveillance de dérive/qualité ; promotion gouvernée. | La qualité du modèle, la dérive, et l’impact métier sont mesurés par rapport à des lignes de base ; le réentraînement est déclenché sur des seuils avec des portails. | Le cycle de vie est entièrement automatisé et auditable ; les voies balisées en libre-service et l’évaluation continue améliorent les modèles à l’échelle de l’organisation à mesure que les données évoluent. |
| IA générative et applications LLM | Sollicitation ad hoc dans des projets isolés ; pas d’ancrage, de garde-fous, ni d’évaluation ; les hallucinations sont découvertes en production. | Un peu de RAG et de versionnage de prompts ; validation de sortie de base ; un petit ensemble d’évaluation manuelle. | Motifs partagés pour RAG, garde-fous, et usage d’outils ; évaluation hors ligne automatisée à chaque changement ; indicateurs en ligne et revue humaine. | Les scores d’évaluation hors ligne et en ligne, les taux d’hallucination et d’injection sont mesurés par rapport à des lignes de base. | L’évaluation est liée aux résultats et s’améliore continuellement ; les défenses contre l’injection, les agents observables gouvernés, et l’atténuation s’adaptent à l’échelle de l’organisation. |
| Développement logiciel assisté par l’IA | Les individus utilisent des assistants ad hoc ; pas de politique ; pas de mesure ; secrets et propriété intellectuelle en danger. | Directives d’usage de base et règles de données ; une certaine analyse de sécurité ; affirmations de productivité anecdotiques. | Normes claires par niveau de risque ; revue et analyse obligatoires ; indicateurs de résultats honnêtes ; déploiement sécurisé et divulgation. | L’impact de l’assistance sur la livraison et la qualité est mesuré par rapport à des lignes de base ; la couverture de vérification est suivie. | La vérification est forte dans le pipeline ; le développement des compétences est délibéré et la politique s’adapte continuellement à mesure que les outils et les preuves changent à l’échelle de l’organisation. |
| IA responsable et digne de confiance | Pas de test d’équité, d’explications, ni de gouvernance ; la responsabilité n’est pas définie ; les problèmes sont découverts seulement après le préjudice. | Un certain test de biais et une documentation ; supervision ad hoc ; sensibilisation aux cadres mais adoption partielle. | Gouvernance cartographiée sur des cadres reconnus ; tests systématiques d’équité/sécurité/vie privée ; supervision et recours documentés ; équipe rouge. | Les indicateurs d’équité, de sécurité, et de vie privée sont surveillés en production par rapport à des lignes de base et des seuils. | La gouvernance est intégrée à la livraison ; la responsabilité est l’affaire de tous et l’approche s’améliore continuellement à travers l’organisation. |
| Infrastructure et opérations IA | Allocation GPU ad hoc ; pas de traitement par lots ni de mise en cache ; pas de visibilité des coûts ; prompts non versionnés ; surveillance minimale. | Une certaine planification et mise en cache partagées ; suivi de coûts de base ; prompts sous contrôle de version ; évaluation ad hoc. | Plateforme partagée avec planification, quotas, traitement par lots, mise en cache, dimensionnement adapté ; infrastructure vectorielle ; évaluation automatisée ; attribution de coûts. | L’utilisation, le coût par résultat, et la latence sont mesurés par rapport à des lignes de base ; les budgets et quotas sont appliqués. | Le routage et la mise à l’échelle sont automatisés, l’observabilité LLMOps est complète, et l’utilisation et le coût sont continuellement optimisés avec la portabilité maintenue à l’échelle de l’organisation. |
Partie 7. Données, analytique, et perspicacité
| Sujet | Niveau 1 Initier | Niveau 2 Développer | Niveau 3 Standardiser | Niveau 4 Gérer | Niveau 5 Orchestrer |
|---|---|---|---|---|---|
| Stratégie et gouvernance des données | Les données ne sont pas documentées ni possédées ; définitions contradictoires ; la qualité est découverte quand les rapports cassent ; pas de catalogue ni de traçabilité. | Certains jeux de données ont des propriétaires et une documentation ; un catalogue partiel ; contrôles de qualité manuels et réactifs ; politique écrite mais faiblement appliquée. | Les produits de données critiques ont des propriétaires, des contrats, des SLA ; catalogue avec traçabilité automatisée ; qualité continue ; gouvernance fédérée. | La qualité des données, la conformité des contrats, et la fraîcheur sont mesurées par rapport aux SLA et lignes de base. | Les données en tant que produit sont la norme ; les contrats sont appliqués automatiquement, les garde-fous en libre-service s’adaptent, et les définitions sont fiables à l’échelle de l’entreprise. |
| Ingénierie des données | Scripts ad hoc, exécutions manuelles, pas de tests ni de surveillance ; les échecs sont découverts par les consommateurs ; coûts non gérés. | Une certaine orchestration et planification ; transformations de base sous contrôle de version ; tests occasionnels ; lutte contre les incendies réactive. | ELT avec des modèles stratifiés, testés, versionnés ; dépendances orchestrées avec nouvelles tentatives/rattrapages ; observabilité ; coûts suivis. | La fiabilité, la fraîcheur, et le coût des pipelines sont mesurés par rapport aux SLA ; les anomalies sont détectées par rapport à des lignes de base. | Les pipelines sont des logiciels avec CI/CD, contrats, et tests ; la plateforme s’améliore continuellement et les nouveaux produits de données se lancent rapidement à l’échelle de l’organisation. |
| Analytique et informatique décisionnelle | Rapports construits ad hoc dans des feuilles de calcul ; indicateurs incohérents ; graphiques trompeurs ; pas de gouvernance. | Un outil de BI avec quelques tableaux de bord partagés ; les définitions d’indicateurs divergent encore ; le libre-service non contrôlé et la prolifération commencent. | Une couche sémantique définit les indicateurs clés une fois ; contenu certifié versus expérimental ; libre-service dans des garde-fous ; cycle de vie géré. | L’usage des indicateurs, la fraîcheur, et les changements de définition sont suivis par rapport à des lignes de base ; le contenu certifié est surveillé. | Les indicateurs sont gouvernés comme des API avec propriétaires et journaux de changements ; l’analytique s’étend du descriptif au prescriptif et s’intègre aux points de décision à travers l’organisation. |
| Analytique produit et expérimentation | Instrumentation faible/incohérente ; décisions par opinion ; pas d’expériences ; indicateurs de vanité ; consentement négligent. | Certains événements sont suivis mais la taxonomie est incohérente ; tests A/B occasionnels sans analyse de puissance ; étoile polaire proposée, non intégrée. | Un plan de suivi gouverné et validé ; entonnoirs/cohortes/rétention routiniers ; expériences sur une plateforme partagée ; consentement correctement géré. | Le volume d’expériences, la puissance, et les taux de succès sont mesurés par rapport à des lignes de base ; la couverture d’instrumentation est suivie. | L’expérimentation est le défaut ; un dépôt de résultats partagé et une instrumentation possédée permettent à l’organisation d’apprendre cumulativement et de s’adapter. |
| Science de la décision et culture des données | Décisions par hiérarchie et intuition ; corrélation traitée comme causalité ; incertitude ignorée ; indicateurs surveillés et manipulés. | Les données sont consultées sélectivement pour justifier des décisions ; une certaine sensibilisation aux pièges causaux ; incertitude rarement communiquée. | Les analyses sont liées aux décisions avec des critères prédéfinis ; corrélation versus causalité distinguée ; incertitude communiquée ; orientation résultats. | La qualité des décisions et la calibration des prévisions sont suivies par rapport aux résultats et lignes de base. | « Qu’est-ce qui changerait notre avis ? » est routinier ; la rigueur causale et l’incertitude honnête sont des normes et les leaders révisent visiblement sur preuves à l’échelle de l’organisation. |
Partie 8. Automatisation
| Sujet | Niveau 1 Initier | Niveau 2 Développer | Niveau 3 Standardiser | Niveau 4 Gérer | Niveau 5 Orchestrer |
|---|---|---|---|---|---|
| CI/CD et livraison | Constructions et déploiements largement manuels et incohérents ; intégration tardive ; publications peu fréquentes et stressantes ; retour en arrière manuel. | Constructions et tests unitaires automatisés par commit ; déploiements scriptés mais supervisés manuellement ; les artefacts peuvent être reconstruits à chaque étape. | Un pipeline standardisé promeut un artefact immuable unique à travers les environnements avec des portails automatisés ; canari/bleu-vert ; enregistrements de changement automatiques. | Les indicateurs DORA (délai, fréquence de déploiement, taux d’échec des changements, MTTR) sont suivis par rapport à des lignes de base et bloquent les retours en arrière. | La livraison progressive découple la publication via des drapeaux de fonctionnalité ; le pipeline s’améliore lui-même et les preuves de conformité sont automatiques à travers l’organisation. |
| Infrastructure en tant que code et configuration | Infrastructure provisionnée manuellement ; environnements incohérents et non documentés ; récupération lente et incertaine. | Une certaine infrastructure scriptée, mais les pratiques varient ; état incohérent ; dérive commune ; politique appliquée par revue manuelle. | IaC déclarative standard à partir de modules partagés versionnés avec état distant ; garde-fous de politique en tant que code ; détection régulière de dérive. | La dérive, le temps de provisionnement, et les taux de violation de politique sont mesurés par rapport à des lignes de base ; les preuves de conformité sont automatiques. | L’infrastructure est immuable, pilotée par GitOps, et auto-réparatrice ; la bibliothèque de modules et de politiques s’améliore continuellement et s’adapte à l’échelle de l’organisation. |
| Conteneurs, orchestration, cloud natif | Conteneurs utilisés ad hoc ; images construites à la main et non analysées ; déploiement manuel ; pas de plateforme partagée ni de modèle d’isolation. | Les équipes conteneurisent et utilisent un orchestrateur, mais les pratiques varient ; analyse et limites incohérentes ; coût et multi-location non gouvernés. | Une plateforme standardisée avec images durcies, portails de signature/analyse, multi-location par espace de noms avec quotas et politique réseau, allocation de coûts. | L’utilisation, la densité, et le coût par charge de travail sont mesurés par rapport à des lignes de base ; l’optimisation FinOps est fondée sur les données. | Une plateforme en libre-service, auto-réparatrice, avec une forte multi-location reste portable et prête pour l’hybride/souverain et s’améliore continuellement à l’échelle de l’organisation. |
| Ingénierie de plateforme et expérience développeur | Pas de plateforme ; chaque équipe assemble son propre outillage de façon incohérente ; transferts pilotés par tickets ; charge cognitive élevée. | Certains outils et modèles partagés, mais fragmentés et partiellement manuels ; libre-service limité ; expérience développeur non mesurée. | Une équipe plateforme exploite des voies balisées, un provisionnement en libre-service, un portail développeur, et des tableaux de bord ; garde-fous dans les voies balisées ; expérience développeur mesurée. | L’adoption, les scores d’expérience développeur, et les signaux de charge cognitive sont mesurés par rapport à des lignes de base et revus. | Un produit de plateforme mature s’améliore continuellement à partir de ces retours ; l’adoption volontaire est élevée et la gouvernance reste invisible dans le flux de travail à l’échelle de l’organisation. |
| Automatisation des tests et des processus | Tests et opérations largement manuels ; couverture incohérente ; procédures dans les têtes ou documents périmés ; preuves de conformité à la main. | Des tests automatisés existent mais sont lents/instables et exécutés de façon incohérente ; certains scripts opérationnels ; remédiation manuelle ; gouvernance par revue périodique. | Infrastructure de test rapide, parallèle, fiable ; livres d’exécution codifiés ; ChatOps ; preuves de conformité générées automatiquement ; gouvernance en tant que vérifications automatisées. | La couverture d’automatisation, les taux de faux positifs, et les temps de remédiation sont mesurés par rapport à des lignes de base. | Les incidents routiniers sont auto-corrigés avec des garde-fous ; la conformité est continue et prête pour l’audit et les humains se concentrent sur le jugement à l’échelle de l’organisation. |
Partie 9. Opérations, fiabilité, et observabilité
| Sujet | Niveau 1 Initier | Niveau 2 Développer | Niveau 3 Standardiser | Niveau 4 Gérer | Niveau 5 Orchestrer |
|---|---|---|---|---|---|
| Ingénierie de fiabilité de site | Opérations manuelles et réactives ; pas de SLO ; la fiabilité est une opinion ; les mêmes incidents se reproduisent ; la lutte contre les incendies domine. | Les services clés ont des SLI/SLO de base ; une certaine surveillance et alerte ; le travail pénible est reconnu mais non mesuré ; post-mortems incohérents. | Les budgets d’erreur influencent la priorisation ; le travail pénible est mesuré et plafonné ; planification de capacité routinière ; automatisation financée ; PRR et modèle d’engagement. | Les budgets d’erreur, le travail pénible, et l’atteinte des SLO sont mesurés par rapport à des lignes de base et guident la priorisation. | La politique de budget d’erreur est automatisée et respectée ; les opérations en libre-service et la capacité proactive permettent à l’organisation d’échanger vélocité et stabilité sur données et de s’adapter. |
| Observabilité et surveillance | Vérifications de disponibilité de base et journaux non structurés par machine ; le débogage signifie SSH ; alertes bruyantes et ignorées. | Métriques centralisées et agrégation de journaux ; quelques tableaux de bord et alertes de seuil ; traces partielles/absentes ; corrélation manuelle. | Instrumentation OpenTelemetry avec identifiants de trace propagés ; journaux structurés, traçage, tableaux de bord organisés, alerte de symptômes SLO ; astreinte durable. | La qualité des alertes, le MTTD, et le coût de la télémétrie sont mesurés par rapport à des lignes de base ; l’alerte par taux de combustion est ajustée aux SLO. | Une observabilité riche en événements et à haute cardinalité soutient l’investigation ad hoc ; la rétention est optimisée en coût et la télémétrie informe les décisions à travers l’organisation. |
| Gestion des incidents | Les incidents sont gérés ad hoc par quiconque les remarque ; pas de rôles, de sévérités, ni de post-mortems ; astreinte informelle ; les échecs se reproduisent. | Rotations d’astreinte et sévérités de base ; certains post-mortems, mais rôles peu clairs et actions correctives suivies de façon incohérente. | Un système formel de commandement d’incident avec des rôles et critères clairs ; post-mortems sans blâme standard ; actions suivies ; astreinte compensée. | La fréquence des incidents, le MTTR, et la charge d’astreinte sont mesurés par rapport à des lignes de base ; les causes récurrentes sont suivies dans le temps. | La réponse est répétée via des journées de jeu ; l’astreinte reste durable et calme et l’analyse agrégée guide l’investissement structurel à mesure que l’organisation apprend. |
| Coût, durabilité, logiciel vert | Les coûts cloud sont une surprise mensuelle ; pas d’étiquetage, d’allocation, ni de sensibilisation au carbone ; provisionnement généreux et non revisité. | Visibilité et étiquetage de coûts de base ; un certain redimensionnement réactif et nettoyage d’inactivité ; la durabilité est reconnue mais non mesurée. | Une pratique FinOps avec attribution, budgets, prévisions, alertes d’anomalie, engagements, redimensionnement ; le carbone est mesuré pour les services majeurs. | Le coût et le carbone sont mesurés par équipe par rapport à des budgets et lignes de base ; les anomalies sont signalées. | Le coût et le carbone sont des signaux continus possédés par les équipes ; les défauts efficaces, l’optimisation automatisée, et la planification sensible au carbone s’améliorent continuellement à l’échelle de l’organisation. |
Partie 10. Gestion de projet/produit/programme
| Sujet | Niveau 1 Initier | Niveau 2 Développer | Niveau 3 Standardiser | Niveau 4 Gérer | Niveau 5 Orchestrer |
|---|---|---|---|---|---|
| Gestion de portefeuille et de programme | Priorités fixées ad hoc par qui demande le plus fort ; pas de vue de portefeuille ; les dépendances émergent en crises ; luttes de financement annuelles. | Un inventaire de portefeuille revu périodiquement ; des objectifs publiés faiblement liés au travail ; un registre de dépendances ; budgétisation par projet. | La stratégie se déploie via les OKR ; un cadre de priorisation cohérent ; la planification inter-équipes gère les dépendances ; financement d’équipe persistant. | Les résultats du portefeuille, la prévisibilité de livraison, et les comptes de dépendances sont mesurés par rapport à des lignes de base. | Le portefeuille est continuellement rééquilibré sur les preuves de résultats ; les dépendances sont conçues pour disparaître et la cadence de financement correspond à la cadence d’apprentissage à l’échelle de l’organisation. |
| Risque, audit, et assurance | Le risque est géré de façon réactive après les incidents ; pas de cadre ni de registre ; contrôles non documentés ; audits manuels douloureux. | Registres de risque pour les systèmes majeurs ; un cadre de contrôle adopté, les audits passent mais sont manuels et ponctuels ; les fournisseurs sont évalués à l’intégration. | Modèle des trois lignes de défense et cadre commun à l’échelle de l’organisation ; beaucoup de contrôles automatisés ; surveillance continue ; inventaires fournisseurs/SBOM ; reprise après sinistre planifiée. | L’efficacité des contrôles, le nombre de risques ouverts, et les constats d’audit sont mesurés par rapport à l’appétit pour le risque et aux lignes de base. | L’assurance est continue et largement automatisée ; les auditeurs échantillonnent des preuves en direct et l’intégrité de la chaîne d’approvisionnement est vérifiée à mesure que les risques évoluent à l’échelle de l’organisation. |
| Approvisionnement, code source ouvert, licences | Le code source ouvert est ajouté librement ; pas de politique ni d’inventaire ; licences non examinées ; la fin de vie est découverte par accident ; pas de propriétaire. | Une politique de base et une liste de licences approuvées ; une certaine analyse manuelle/tardive ; un inventaire pour les systèmes majeurs ; contribution ad hoc. | Un OSPO possède la stratégie et l’outillage ; analyse automatisée de licences/vulnérabilités et attribution ; SBOM ; contribution claire ; fin de vie suivie. | La conformité des licences, la fraîcheur des dépendances, et l’exposition aux vulnérabilités sont mesurées par rapport à des lignes de base. | Le code source ouvert est un actif stratégique géré avec une conformité entièrement automatisée ; l’investissement en amont est délibéré et la fraîcheur et la fin de vie sont gérées en continu à l’échelle de l’organisation. |
| Soutenir les systèmes grands et de longue durée | Les systèmes dépendent de héros ; propriété par mémoire ; savoir non documenté ; les systèmes sont gelés jusqu’à ce qu’ils cassent ; les retraits ne se terminent jamais. | Propriété assignée et enregistrée pour les systèmes majeurs ; certains documents et livres d’exécution ; les fonctions critiques évidentes ont une personne de secours ; maintenance réactive. | Propriété au niveau de l’équipe dans un catalogue qui survit aux réorganisations ; le facteur bus est mesuré et atténué ; enregistrements de décision et livres d’exécution ; modernisation incrémentale. | Le facteur bus, la couverture de propriété, et le progrès de transfert de connaissances sont mesurés par rapport à des lignes de base. | L’intendance est une discipline financée ; aucun système critique n’est un point unique de défaillance humaine et le transfert de connaissances et les fins planifiées se poursuivent à l’échelle de l’organisation. |
| Éthique, responsabilité, intérêt public | L’éthique n’est pas abordée ou l’est de façon réactive après un scandale ; l’accessibilité est ignorée ; décisions automatisées opaques sans recours ; le biais n’est pas testé. | Un code de conduite et une certaine accessibilité (tardive) ; les décisions automatisées à fort enjeu reçoivent une certaine supervision ; vérifications de biais occasionnelles. | La revue éthique fait partie du processus ; l’accessibilité est conçue dès le départ et testée par les utilisateurs ; les décisions conséquentes portent une explication et un recours. | L’équité, l’accessibilité, et les résultats de responsabilité algorithmique sont surveillés par rapport à des lignes de base. | La responsabilité est intégrée dans la façon dont l’organisation construit ; l’équité est un défaut non négociable et la responsabilité algorithmique est standard et continuellement améliorée à l’échelle de l’organisation. |
Auto-évaluation globale de maturité
Utilisez les matrices ci-dessus pour produire un score léger et honnête.
Grille de notation
- Notez chaque chapitre de 1 à 5 en utilisant le niveau dont la description correspond le mieux à votre réalité typique. Quand le comportement est incohérent, notez le niveau inférieur.
- Faites la moyenne par partie. Additionnez les scores des chapitres d’une partie et divisez par le nombre de chapitres. Cela donne une maturité par partie (par exemple, « la partie IV a une moyenne de 2,5 »).
- Enregistrez le minimum, pas seulement la moyenne. Une partie qui a une moyenne de 3,0 mais contient un chapitre de niveau 1 porte quand même le risque de ce chapitre.
- Tracez la tendance. Réévaluez chaque trimestre ou deux et observez la direction du mouvement. Un domaine qui passe de 2 à 3 est plus sain qu’un domaine bloqué à un 3 statique.
Une feuille de calcul simple par partie :
| Partie | Chapitres notés | Moyenne | Chapitre le plus bas | Notes / priorité |
|---|---|---|---|---|
| I-X | nombre | moyenne | niveau min | … |
Prioriser ce qu’il faut améliorer
N’essayez pas de tout élever en même temps, et ne poursuivez pas la moyenne la plus haute. Priorisez par écart de maturité pondéré par le risque : attaquez les domaines où un niveau bas rencontre une conséquence élevée.
- D’abord : les chapitres à la plus faible maturité dans vos domaines à plus haut risque. Pour la plupart des organisations, cela signifie la sécurité, la vie privée, la fiabilité, la conformité, et tout système dont l’échec nuit aux personnes ou viole la loi. Un niveau 1 ici est urgent.
- Ensuite : les facilitateurs fondamentaux (culture, façons de travailler, CI/CD, IaC, observabilité) qui élèvent le plafond pour chaque autre domaine. Améliorer ceux-ci rend les gains ultérieurs moins coûteux.
- Plus tard : les domaines déjà au niveau 3 qui pourraient grimper au niveau 4 ou 5. Ne poussez au-delà du plancher que là où les enjeux et l’échelle justifient l’investissement supplémentaire.
Le plancher de la grande entreprise et du gouvernement
Les contextes de grande entreprise et de gouvernement ne peuvent généralement pas s’arrêter à « ça marche ». Pour passer les audits, maintenir les autorisations, et satisfaire les obligations réglementaires et de responsabilité publique, la plupart des domaines doivent atteindre au moins le niveau 3 (Standardiser), le niveau où les pratiques sont standardisées, documentées, appliquées à travers les équipes, et produisent des preuves. Le niveau 2 échoue typiquement à l’audit parce qu’il est incohérent et assemblé manuellement sous délai ; le niveau 1 échoue purement et simplement.
Lisez le niveau 3 comme le plancher pour tout ce qui est auditable ou pertinent pour la sécurité, et les niveaux supérieurs (4 et 5) comme des cibles seulement là où l’assurance continue, l’échelle, ou la confiance publique rendent la rigueur supplémentaire rentable. La maturité reste un moyen : l’objectif est un niveau de contrôle défendable et proportionné au risque que vous portez réellement, pas un score parfait.