Recette métier : qui autorise la mise en production ?

Le prestataire a terminé sa démonstration. Le chef de projet annonce que l’application est prête. Le responsable métier répond qu’il fera tester son équipe dès qu’elle aura un moment. Pourtant, la date de lancement reste au calendrier.

Je me méfie de cette situation : chacun peut croire que la validation appartient à quelqu’un d’autre. La DSI finit alors par ouvrir le service parce que rien ne semble bloquer. Au premier dossier impossible à traiter, elle découvre que personne n’avait réellement accepté le fonctionnement livré.

Désigner les responsables de la validation avant les essais

Je sépare d’abord les responsabilités. Les utilisateurs exécutent des tâches représentatives. Le responsable métier juge si les résultats permettent de travailler et si les écarts restants sont supportables. La DSI se prononce sur les conditions techniques, la sécurité et l’exploitation. Le commanditaire, ou le décideur qu’il a désigné, autorise le lancement à partir de ces avis.

Cette répartition tient sur une page. Elle doit comporter des noms et un remplaçant en cas d’absence. Écrire que le comité projet valide ne suffit pas : il faut savoir qui tranche lorsqu’un responsable métier souhaite ouvrir et que l’exploitation n’est pas prête.

Dans son guide Dynamics 365, Microsoft présente la recette utilisateur comme une validation par les métiers avant le déploiement. Je retiens ce principe pour organiser la décision, sans imposer toute la méthode d’un projet ERP à une petite application interne.

Une date réservée au planning ne constitue pas une autorisation de mise en production.

Ce cadre organise la décision interne. Si un procès-verbal doit aussi déclencher une réception contractuelle ou un paiement, je fais relire sa portée par les achats avant de le soumettre à signature.

Écrire les parcours indispensables avec le métier

Une liste d’écrans à ouvrir donne peu d’informations sur la capacité à travailler. Je demande plutôt au responsable métier de décrire ce qu’un utilisateur doit pouvoir terminer : enregistrer une demande, la faire approuver, corriger une erreur et retrouver le résultat dans le système destinataire.

Chaque parcours comporte un point de départ, un profil utilisateur, des données préparées et un résultat attendu. Le testeur doit pouvoir constater ce résultat sans que le prestataire lui explique après coup pourquoi ce qui apparaît à l’écran est finalement correct.

Voici un exemple fictif pour une application de demandes d’achat. Les scénarios sont à adapter aux règles réellement décidées par l’entreprise.

Je commence par les parcours indispensables, puis j’élargis aux variantes. Cette priorité ne dispense pas de tester le reste : elle empêche simplement de consacrer toute la disponibilité du métier à des détails de présentation.

Faire exécuter les tests dans des conditions crédibles

Une démonstration pilotée par l’intégrateur peut aider à comprendre l’application. Elle ne prouve pas qu’un utilisateur sait accomplir sa tâche. Pendant la recette, je fais donc manipuler les personnes qui travailleront avec le service, après leur avoir présenté son fonctionnement.

Les profils doivent correspondre aux droits prévus. Un essai réalisé avec un compte administrateur peut masquer un accès manquant ou une possibilité de modification excessive. Les données doivent couvrir les cas attendus, y compris les dossiers incomplets et les erreurs de saisie. Je privilégie des jeux synthétiques représentatifs lorsque les données de production ne sont pas nécessaires.

Le Service Manual britannique sur l’assurance qualité recommande de tester le service dans des conditions normales et inhabituelles, ainsi que son utilisabilité. Pour une DSI d’ETI, j’en tire une consigne simple : faire essayer aussi ce qui se passe lorsque le parcours ne suit pas le chemin prévu.

Le compte rendu précise la version testée, l’environnement, l’auteur de l’essai et la preuve obtenue. Une capture peut suffire pour un affichage ; une transmission demande de vérifier aussi l’arrivée dans le système cible. Toute correction doit conduire à rejouer le scénario concerné et les parcours qu’elle risque d’affecter.

Classer les anomalies selon leurs conséquences

Je déconseille de décider sur un taux global de réussite. Une longue liste de contrôles réussis peut laisser hors champ le seul parcours qui permet de terminer l’activité. La question utile est de savoir ce qui reste impossible, incertain ou excessivement lourd à réaliser.

Je distingue les blocages, les réserves acceptables et les améliorations. Un blocage empêche une activité indispensable ou rend son résultat incontrôlable. Une réserve permet de travailler avec un contournement vérifié et supportable. Une amélioration concerne un fonctionnement utilisable que le métier souhaite faire évoluer.

Cette qualification se discute avec le métier. Un export manuel peut sembler acceptable à la DSI et immobiliser la personne chargée de l’effectuer au moment où elle doit traiter les urgences. Je demande qui exécutera le contournement, à quel rythme et jusqu’à quelle date. Sans réponse, la réserve n’est pas instruite.

Le registre conserve l’anomalie, sa conséquence, le responsable de correction, l’échéance et la preuve de clôture attendue. Ce suivi rejoint la nécessité de rendre les arbitrages techniques visibles. Une réserve acceptée au lancement doit rester suivie après la dissolution de l’équipe projet.

Distinguer la recette métier de la préparation de l’exploitation

Le métier peut réussir tous ses parcours sans que le service soit exploitable. Il reste à savoir qui reçoit les alertes, qui répond aux utilisateurs, comment diagnostiquer un incident et qui peut suspendre l’ouverture. Je demande à l’équipe qui reprendra le service de confirmer ces points avant la réunion de lancement.

Les revues de préparation opérationnelle décrites par AWS s’appuient sur des questions issues des incidents pour examiner les risques d’exploitation. Je retiens l’intérêt d’une liste adaptée à nos propres incidents, plutôt qu’un formulaire générique signé sans discussion.

Le retour arrière mérite une réponse précise. Une ancienne version disponible ne suffit pas si de nouvelles opérations ont déjà été enregistrées. Le dossier doit expliquer ce qu’il advient des données produites depuis l’ouverture et comment l’activité reprend. Si le retour est impossible, il faut préparer une autre mesure de continuité et rendre cette limite visible.

Je ne transforme pas cette revue en audit interminable. Une application limitée appelle un dispositif proportionné. En revanche, la taille du projet ne justifie pas de laisser le support découvrir son existence au premier appel.

Consigner une décision utilisable après la réunion

Le document de décision rassemble le périmètre et la version, les parcours validés, ceux qui ne l’ont pas été, les anomalies ouvertes et les avis métier et DSI. Il indique ensuite la décision : ouverture, ouverture limitée à un périmètre explicitement validé, ou report avec conditions de réexamen.

Je refuse la formule selon laquelle l’absence de retour vaut accord. Si le métier n’a pas pu tester, le commanditaire doit arbitrer la disponibilité des personnes, le périmètre ou la date. Un report a un coût ; une ouverture sans preuve comporte un risque. Les présenter ensemble permet une décision assumée.

Une ouverture sous conditions exige aussi un responsable chargé de vérifier leur réalisation avant d’exécuter la bascule. Une promesse de correction ne devient pas une preuve parce qu’elle figure dans un compte rendu.

Pour démarrer la semaine prochaine, je prendrais un seul projet proche du lancement. Je réunirais le responsable métier et la personne qui l’exploitera pour écrire les parcours indispensables et nommer le décideur. Je réserverais ensuite les créneaux d’essai et de reprise des anomalies. Le premier résultat attendu est très concret : savoir quelle preuve manque encore pour autoriser l’ouverture.