1. Le constat : 80% des cartos sont incomplètes
Une carto applicative type contient : nom, code, domaine, type, statut, hébergeur, un ou deux contacts. C'est déjà mieux que rien — mais insuffisant dès qu'un DSI, un RSSI ou un auditeur pose une des 5 questions suivantes :
- ➜ « Quelles apps sont critiques au sens DORA ? » Réponse VIP oui/non ⇒ échec — DORA exige une échelle de criticité, un RTO et un RPO documentés.
- ➜ « Quelles apps traitent de la donnée RGPD sensible ? » Pas de classification ⇒ chaque app doit être ré-auditée individuellement.
- ➜ « Combien coûte l'app X répartition licence/support/infra/staff ? » Montant unique ⇒ impossible de piloter la rationalisation TCO.
- ➜ « Qui est le DPO de cette app ? Et l'architecte ? » Un seul « Contact IT » ⇒ pas d'accountability croisée.
- ➜ « Qui a modifié la criticité MISSION_CRITICAL le 15 juin ? » Pas d'audit trail ⇒ non-conformité DORA Article 8.
Chacune de ces questions correspond à un champ ou un pattern qu'on va détailler. La bonne nouvelle : ces 5 dimensions peuvent être ajoutées progressivement, sans big-bang de migration, à condition d'utiliser le pattern additive N-1 compat.
2. Criticité — 4 niveaux plutôt que VIP oui/non
Le booléen « VIP » est un anti-pattern qui rassemble deux notions distinctes : impact business (arrêt court tolérable ou pas ?) et engagement de continuité (RTO cible ?). L'échelle standard, alignée sur le cadre DORA :
| Niveau | Signification | RTO typique |
|---|---|---|
| MISSION_CRITICAL | Indispensable — arrêt = perte revenu immédiate ou infraction réglementaire | ≤ 4h |
| IMPORTANT | Arrêt court tolérable (heures) — impact business significatif | 4-24h |
| NOMINAL | Défaut — pas de SLA fort, best-effort acceptable | ≤ 72h |
| LOW | Fin de vie / obsolescence — pas d'engagement de continuité | — |
Migration pragmatique depuis un booléen VIP : VIP=true → MISSION_CRITICAL, VIP=false → NOMINAL. L'équipe métier affine ensuite les IMPORTANT et LOW au fil de l'eau. Le défaut NOMINAL évite d'introduire du null en base.
3. RTO et RPO — le vocabulaire DORA
Deux acronymes indispensables pour parler continuité de service :
Durée maximale d'interruption acceptable entre l'incident et le rétablissement. Ex: RTO = 4h ⇒ on tolère 4h de coupure max. Ne pas confondre avec RTA (Recovery Time Actual — le temps réel mesuré en post-mortem).
Perte de données maximale acceptable mesurée en unité de temps. Ex: RPO = 1h ⇒ on tolère de perdre les dernières 60 minutes de transactions. Détermine la fréquence de backup / réplication.
Ces deux valeurs doivent être documentées par appet cohérentes avec la criticité. Un incohérence typique : app marquée MISSION_CRITICAL avec RTO à 48h ⇒ soit la criticité est fausse, soit le budget continuité est sous-dimensionné. L'audit DORA cherche exactement ces incohérences.
4. Classification de la donnée + tags réglementaires
Deux dimensions complémentaires souvent confondues :
Data Classification — 4 niveaux standards (PUBLIC / INTERNAL / CONFIDENTIAL / RESTRICTED) qui décrivent la sensibilité intrinsèque de la donnée. Le défaut INTERNAL évite les faux « PUBLIC » par omission.
Regulatory Tags — set multi-valeur des réglementations applicables. Une app bancaire peut être DORA + RGPD + PCI_DSS, une app santé HDS + RGPD. Le tag ne signifie pas « conforme » mais « scope applicable ».
Piège fréquent : ne stocker que la classification et oublier les tags. Résultat : impossible de filtrer « toutes les apps DORA » ou « toutes les apps NIS2 » — chaque audit devient une extraction manuelle.
5. TCO éclaté — bench LeanIX/Ardoq
Un montant unique annualCost est insuffisant pour piloter la rationalisation. Le standard portfolio management impose 4 composantes :
Abonnements SaaS, licences perpétuelles, contrats vendor.
Contrats de maintenance, TMA, support éditeur.
Hébergement, hardware, coûts cloud AWS/Azure/GCP.
Équipe interne allouée (dev, run, product) en équivalents temps plein.
L'éclatement débloque plusieurs cas d'usage clés : « combien de licences SaaS mutualisables ? », « quel % de mon SI est coût staff ? », « quelle app est trop chère par utilisateur ? ». Un pattern de migration transparent : garder annualCost comme getter dérivé (somme des 4 si ≥ 1 renseignée, sinon legacy) pendant 1 release, puis DROP.
6. Multi-rôles M:N — au-delà de « Contact IT »
Un seul « Contact IT » et un « Contact Métier » ne couvrent pas la réalité d'une accountability moderne. Le pattern M:N standard portfolio management définit 6 rôles :
- Product Owner — owner métier / stratégie produit
- Business Owner — sponsor métier / decision owner
- Tech Lead — responsable technique (dev / run)
- Architecte — architecte solution référent
- Security Officer — RSSI référent
- Data Owner / DPO — owner de la donnée (RGPD)
La cardinalité est M:N (plusieurs personnes pour un rôle, plusieurs rôles pour une personne). Backfill pragmatique depuis le legacy : contactIT → TECH_LEAD, contactMetier → PRODUCT_OWNER.
7. Audit trail — « qui a modifié quoi »
Le dernier verrou compliance : chaque changement sur les fields sensibles doit être tracé. DORA Article 8 (contrôle interne) et NIS2 Article 21 (gestion des risques) exigent une preuve de qui a modifié la criticité, la classification ou les rôles, et quand. Un simple « updated_at » ne suffit pas — il faut le delta before/after par field.
La bonne implémentation : une table dédiée application_change_log alimentée à chaque save via un snapshot BEFORE / AFTER des fields whitelistés. Un tab Historique dans la fiche complète affiche la timeline reverse-chronological. La rétention typique est de 2 ans avec purge automatisée.
Attention à un piège : logger tous les fields devient bruyant. La whitelist doit contenir uniquement les fields à impact compliance : criticité, classification, réglementations, rôles, RTO/RPO, TCO, statut. Le nom ou la description n'ont pas besoin d'audit trail dédié (le simple updated_at suffit).
8. Checklist d'un AppService audit-ready
Un AppService prêt pour un audit DORA / NIS2 / RGPD contient a minima :
- Criticité sur échelle 4 niveaux (pas de booléen VIP)
- RTO et RPO chiffrés en heures, cohérents avec la criticité
- Data classification (PUBLIC / INTERNAL / CONFIDENTIAL / RESTRICTED)
- Tags réglementaires multi-valeur (DORA / NIS2 / RGPD / …)
- Flag DCP (données à caractère personnel) explicite
- TCO éclaté en 4 composantes (licence / support / infra / staff)
- Multi-rôles typés (PO / BO / TL / Architecte / RSSI / DPO)
- Audit trail des changements sur ces fields whitelistés
Bonne nouvelle : ces 8 dimensions peuvent être ajoutées progressivementsans big-bang de migration, à condition d'utiliser le pattern additive N-1 compat (ADD nullable + backfill + kept legacy 1 release + DROP). Compter 1 sprint de 2-3 semaines par vague de 3-4 fields.