Le plan de recette : vérifier que tout fonctionne après migration

Une fois la nouvelle solution déployée, une question décisive se pose : fonctionne-t-elle réellement comme attendu ? Y répondre méthodiquement, plutôt que de le supposer, est le rôle du plan de recette. Cette étape de vérification systématique, avant de considérer la migration comme achevée, sépare les projets maîtrisés des projets qui découvrent leurs défauts en production, aux dépens des utilisateurs. Souvent négligée dans l’enthousiasme de la mise en service, la recette est pourtant une garantie essentielle. Cet article présente le plan de recette d’une migration télécom, à l’usage des décideurs et chefs de projet.

Ce qu’est la recette et pourquoi elle compte

La recette est la phase de vérification méthodique au cours de laquelle on teste que la solution livrée répond bien aux besoins exprimés, avant de la valider définitivement. Elle consiste à passer en revue, de façon systématique, l’ensemble des fonctions et des cas d’usage attendus, pour confirmer qu’ils fonctionnent, ou identifier ce qui doit être corrigé. Son importance tient à une réalité simple : une solution peut sembler fonctionner dans son ensemble tout en présentant des défauts sur des cas particuliers, qui ne se révéleront qu’à l’usage, parfois au plus mauvais moment. La recette vise à débusquer ces défauts en amont, dans un cadre contrôlé, plutôt que de les laisser surgir en production. Elle transforme la mise en service d’un pari en une certitude vérifiée. C’est le moment où l’on s’assure, preuve à l’appui, que le service est au rendez-vous.

Que vérifier : les fonctions essentielles

Un plan de recette couvre méthodiquement les fonctions attendues. Pour la téléphonie, cela inclut de tester chaque numéro, en émission et en réception, les transferts d’appels, la mise en attente, la messagerie vocale, le standard automatique et les files d’attente, les groupes d’appels, les renvois. Il s’agit de vérifier que chaque ligne sonne correctement, que les numéros conservés par portabilité fonctionnent, que l’acheminement des appels entrants suit bien les règles définies. La qualité audio elle-même fait l’objet de tests : absence de coupures, de décalages, de dégradations. Chaque fonction utilisée par l’organisation doit figurer au plan et être effectivement testée, plutôt que supposée fonctionnelle. Cette revue exhaustive, fastidieuse mais indispensable, est le cœur de la recette : ne rien laisser au hasard parmi les usages sur lesquels l’organisation compte au quotidien.

Ne pas oublier les cas particuliers

Au-delà des fonctions courantes, la recette doit accorder une attention particulière aux cas critiques et aux usages spécifiques, précisément ceux dont la défaillance serait la plus grave. Les appels d’urgence et la localisation associée doivent être testés, enjeu de sécurité majeur. Les usages techniques migrés, alarmes, terminaux de paiement, dispositifs divers, doivent être vérifiés dans leur fonctionnement réel, et non seulement dans leur raccordement. Le comportement de la solution en cas d’incident réseau, la bascule vers un secours le cas échéant, mérite d’être éprouvé. Ces cas particuliers, moins fréquents mais souvent les plus sensibles, sont ceux qu’une recette superficielle laisse de côté et qui provoquent les incidents les plus dommageables. Les intégrer explicitement au plan de recette est une marque de rigueur, à la mesure de leur criticité. C’est là que se révèle la différence entre une recette de forme et une recette sérieuse.

Comment mener la recette

La recette gagne à être conduite avec méthode. Elle repose sur un document, le plan de recette, listant l’ensemble des points à vérifier, chacun assorti du résultat attendu, de sorte que le testeur puisse cocher ce qui fonctionne et signaler ce qui ne va pas. Elle implique idéalement les utilisateurs, ou un échantillon représentatif, capables de tester les usages réels mieux que quiconque, dans une logique de validation par ceux qui se serviront de la solution. Elle distingue les anomalies bloquantes, qui interdisent la validation tant qu’elles ne sont pas corrigées, des réserves mineures, qui peuvent être traitées ultérieurement. Elle donne lieu à un procès-verbal actant la validation, ou les corrections requises. Cette formalisation, loin d’être une lourdeur bureaucratique, protège l’organisation en objectivant l’état réel de la solution et en engageant le prestataire sur les corrections.

La recette, condition de la validation

La recette occupe une place précise dans le déroulement du projet : elle conditionne la validation de la migration et, souvent, le règlement final du prestataire. Une migration ne devrait pas être considérée comme achevée, ni l’ancien accès résilié, tant que la recette n’a pas confirmé le bon fonctionnement du nouveau. Cette articulation renforce l’intérêt du recouvrement, la période de coexistence des accès offrant le cadre idéal pour mener la recette sans risque. Faire de la recette une étape obligatoire, formalisée et sérieuse, plutôt qu’une vérification expédiée, est une garantie que l’organisation se donne à elle-même. C’est le point de contrôle qui assure que le service promis est effectivement livré, et le moment légitime pour n’accepter la solution qu’une fois sa conformité démontrée. En cela, la recette est un outil de maîtrise autant que de vérification.

En synthèse

Le plan de recette est la vérification méthodique que la solution livrée fonctionne comme attendu, avant de valider la migration. Il couvre exhaustivement les fonctions de téléphonie, chaque numéro, transfert, messagerie, standard, en portant une attention particulière aux cas critiques, appels d’urgence, usages techniques, comportement en incident. Mené avec méthode, formalisé dans un document et impliquant les utilisateurs, il distingue anomalies bloquantes et réserves mineures et débouche sur une validation actée. Il conditionne l’achèvement de la migration et se mène idéalement pendant la période de recouvrement. Loin d’être une formalité, la recette est la garantie que le service promis est réellement au rendez-vous.

Cet article présente un cadre général et ne se substitue pas à un plan de recette adapté à chaque organisation. Le contenu des tests dépend des fonctions et usages propres à chaque structure. Sources : documentation publique d’intégrateurs et retours d’expérience sur les projets de migration télécom.

Pour aller plus loin

• Le recouvrement des liens : basculer sans coupure de service
• Piloter une migration télécom multisite : méthode et étapes
• Check-list de migration télécom : les 10 points à ne pas négliger

À lire aussi dans ce dossier

• QoS et qualité de la voix sur IP : les prérequis réseau à vérifier
• La portabilité des numéros : ce que dit précisément la réglementation Arcep
• Les terminaux de paiement après le cuivre : solutions de remplacement
• Fermeture du cuivre : que se passe-t-il pour les usages non migrés le jour de la coupure ?