Comment évaluer la préparation à la production d’une application métier

La production commence après la démonstration

Une démonstration prouve qu’un parcours fonctionne dans des conditions préparées. La production exige que le système fonctionne avec des utilisateurs réels, des données imparfaites, des intégrations indisponibles, des changements simultanés et des personnes qui ont besoin d’aide. La différence réside moins dans le nombre de fonctionnalités que dans la capacité à exploiter le produit.

Une revue de préparation à la production est un mécanisme de décision. Elle réunit métier, produit, développement, opérations, sécurité, données et support. Chaque constat doit avoir une preuve, un risque, un propriétaire et une date. Le but n’est pas de rendre le lancement impossible, mais de distinguer le risque accepté du risque ignoré.

Les neuf dimensions de la revue

• Valeur et périmètre: utilisateurs, parcours critiques, critères d’acceptation et fonctions explicitement hors périmètre.
• Architecture: dépendances, capacités, limites, points uniques de défaillance et comportement en mode dégradé.
• Sécurité: identités, privilèges, secrets, vulnérabilités, journalisation et réponse aux incidents.
• Données: qualité, migration, sauvegarde, rétention, confidentialité, traçabilité et reprise.
• Qualité: tests fonctionnels, non-régression, performance, compatibilité et cas d’échec.
• Déploiement: environnements cohérents, automatisation, migration, rollback ou rollforward et validation après release.
• Observabilité: métriques métier et techniques, journaux, traces, alertes actionnables et tableaux de bord.
• Continuité: objectifs de reprise, sauvegardes, exercices, fournisseurs et fonctionnement manuel temporaire.
• Exploitation et support: propriétaire, astreinte, niveaux de sévérité, runbooks, formation et communication.

Noter sans masquer les risques critiques

Une échelle de 0 à 5 facilite la discussion. Zéro signifie absent ou inconnu. Un indique une intention sans preuve. Deux indique une mise en œuvre partielle. Trois correspond au niveau prévu, démontré dans l’environnement adapté. Quatre ajoute des tests réguliers et des mesures. Cinq correspond à une capacité optimisée par retour d’expérience.

La moyenne ne doit jamais compenser un bloqueur. Une application notée quatre partout mais sans restauration testée peut rester un No-Go si la perte de données met l’entreprise en danger. De même, une faille d’autorisation inter-rôles, une migration irréversible non testée ou l’absence de propriétaire en cas d’incident doivent être examinées séparément.

Dix bloqueurs qui justifient de reporter

• Aucun propriétaire métier ou technique capable de décider en incident.
• Accès administrateur partagé, non protégé ou non traçable.
• Sauvegarde présente mais aucune restauration aboutie.
• Migration de données sans réconciliation ni plan de retour.
• Secret de production exposé dans le code, les journaux ou un poste non maîtrisé.
• Parcours de commande, paiement ou facturation non idempotent.
• Aucune alerte sur l’indisponibilité du parcours critique.
• Dépendance externe sans timeout, reprise ou contact d’escalade.
• Support non formé et incidents sans classification ni communication.
• Risque légal ou contractuel critique non analysé par le bon responsable.

Un dossier de preuve compact

Le dossier ne doit pas devenir une archive illisible. Il peut contenir une carte d’architecture, la matrice des rôles, les résultats de tests critiques, le plan de migration, le résultat de restauration, les tableaux de bord, les runbooks, la matrice de support et le registre des risques résiduels. Chaque lien a un propriétaire et une date de vérification.

La revue doit aussi vérifier la capacité humaine. Une procédure parfaite n’a aucune valeur si la personne d’astreinte ne peut pas accéder aux outils, si le support ignore les messages à envoyer ou si le métier ne sait pas basculer en mode dégradé.

Exemple anonymisé: lancement d’un portail fournisseur

Le portail passe les tests fonctionnels et l’équipe souhaite ouvrir à tous les fournisseurs. La revue révèle deux écarts: les imports peuvent être rejoués en doublon et les sauvegardes n’ont pas été restaurées dans le nouvel environnement. Le tableau global reste satisfaisant, mais ces deux points touchent les données métier.

La décision est Go conditionnel pour un groupe pilote limité. Une clé d’idempotence est ajoutée, la restauration est testée, le support suit les imports et une réconciliation quotidienne détecte les écarts. L’ouverture générale dépend des preuves obtenues pendant le pilote.