Un projet SaaS métier réussi laisse derrière lui plus que des utilisateurs connectés : il produit un patrimoine documentaire qui sécurise l'organisation, aide à décider, à former, à auditer et, le jour venu, à changer de solution. Ce patrimoine est le travail de l'assistance à maîtrise d'ouvrage (AMOA). Voici les cinq livrables que nous produisons systématiquement, ce que chacun contient et les questions à se poser pour vérifier qu'il est solide.
L'AMOA en deux mots
La maîtrise d'ouvrage, c'est vous : l'organisation qui exprime le besoin et valide le résultat. L'AMOA est l'accompagnement d'un expert indépendant, qui traduit les besoins métier en exigences claires, suit le prestataire (éditeur SaaS ou équipe de développement) et sécurise la recette et la mise en service. Son rôle est détaillé dans notre article pourquoi confier le pilotage de votre projet digital à un consultant indépendant, et sur la page de notre service d'assistance à maîtrise d'ouvrage.
1. Le cahier des charges fonctionnel
C'est le document fondateur : il décrit ce que la solution doit permettre de faire, sans prescrire comment la construire. Il est rédigé en termes métier, pour être compris des utilisateurs comme des prestataires. Un cahier des charges solide comporte :
- le contexte et les objectifs du projet, avec les indicateurs qui diront s'il a réussi ;
- la description des processus actuels et des processus cibles ;
- les exigences fonctionnelles, priorisées (par exemple selon la méthode MoSCoW : indispensable, souhaitable, utile, exclu) ;
- les exigences non fonctionnelles : sécurité, disponibilité, hébergement, langues, accessibilité ;
- les interfaces avec les systèmes existants.
Il est validé par les utilisateurs clés avant la mise en concurrence des prestataires, de manière que toutes les offres répondent au même besoin et puissent être comparées. Si vous hésitez entre un produit du marché et un développement sur mesure, ce document sert aussi de base à la comparaison, comme nous l'expliquons dans développement spécifique ou SaaS standard.
2. Le plan de tests de recette
La recette est l'étape où vous décidez d'accepter, ou non, la solution. Le plan de tests la rend objective : plutôt que d'essayer l'outil au hasard, on déroule des scénarios écrits à l'avance, avec des critères d'acceptation explicites.
Ce que doit couvrir le plan
- des scénarios fonctionnels sur les cas nominaux et sur les cas limites ;
- des tests par persona métier (comptable, responsable, agent de terrain), car chacun n'utilise pas l'outil de la même façon ;
- des tests de migration de données, pour vérifier que l'historique est repris sans perte ni doublon ;
- des tests de performance et de charge, représentatifs du nombre d'utilisateurs réel ;
- la grille de qualification des anomalies (bloquante, majeure, mineure) et la règle de décision associée.
La logique de recette par scénarios est la même que celle de notre méthode de développement spécifique.
3. Le plan de déploiement
Passer en production n'est pas un interrupteur. Le plan de déploiement organise la bascule pour que l'activité ne s'arrête pas :
- la stratégie de bascule : big bang (tout le monde le même jour) ou progressive (par site, direction ou équipe) ;
- la gestion des données historiques : ce qui est repris, archivé ou abandonné ;
- le calendrier, en évitant les périodes de forte activité (clôtures, campagnes) ;
- la cellule de support des premiers jours et le circuit de remontée des problèmes ;
- le plan B : les conditions dans lesquelles on revient à l'ancien fonctionnement, et comment.
4. Le plan de formation
Un outil qui n'est pas maîtrisé n'est pas adopté. Le plan de formation traite la conduite du changement de façon concrète :
- un parcours par profil (administrateur, saisie, validation, consultation), plutôt qu'une formation unique pour tous ;
- des supports pédagogiques adaptés aux usages réels : guides pas à pas, fiches rapides, vidéos courtes ;
- le repérage et la formation des super-utilisateurs, relais de proximité auprès de leurs collègues ;
- un plan de communication interne : pourquoi on change, ce que cela apporte, quand et à qui s'adresser ;
- un suivi après la mise en production pour repérer les difficultés d'usage.
5. Le plan de réversibilité
C'est le livrable que l'on néglige le plus, et celui qui protège le plus. Avec un SaaS, vos données vivent chez un tiers. Le plan de réversibilité décrit à l'avance les conditions de votre désengagement :
- les données récupérables et leur format (formats ouverts de préférence) ;
- les modalités et délais de restitution à la fin du contrat ;
- la suppression certifiée des données chez le prestataire après restitution ;
- l'accompagnement technique de la transition vers une autre solution ;
- la continuité du service pendant la période de transition.
Ces conditions se négocient avant la signature, quand vous avez encore le choix du prestataire, et non au moment de la rupture.
Les 5 livrables en un coup d'œil
| Livrable | Moment | Question à laquelle il répond |
|---|---|---|
| Cahier des charges fonctionnel | Avant la consultation | Que doit permettre la solution ? |
| Plan de tests de recette | Avant la recette | Comment décider d'accepter la solution ? |
| Plan de déploiement | Avant la bascule | Comment passer en production sans arrêter l'activité ? |
| Plan de formation | Avant et après la bascule | Comment garantir que l'outil sera utilisé ? |
| Plan de réversibilité | Avant la signature | Comment récupérer nos données si nous partons ? |
Ces livrables s'enchaînent et se répondent : les exigences du cahier des charges alimentent les scénarios de recette, qui conditionnent la date de bascule, laquelle détermine le calendrier de formation. Les produire dans le désordre, ou les confier à des interlocuteurs différents sans les relier, est la source de la plupart des écarts constatés en fin de projet. C'est pourquoi nous les traitons comme un ensemble cohérent, tenu à jour par la même équipe tout au long du projet, de la consultation à la sortie éventuelle du dispositif.
Checklist : vos 5 livrables sont-ils solides ?
- Le cahier des charges est-il signé par les utilisateurs clés, et non par la seule direction informatique ?
- Les exigences sont-elles priorisées, avec ce qui est exclu du périmètre ?
- Chaque scénario de recette a-t-il un critère d'acceptation écrit ?
- Le plan de déploiement prévoit-il explicitement un retour en arrière ?
- Chaque profil d'utilisateur a-t-il son parcours de formation ?
- Les conditions de sortie (données, délais, suppression) figurent-elles au contrat ?
En pratique
Ces cinq livrables sont notre standard sur tout projet SaaS. Ils protègent l'organisation contre les mauvaises surprises et facilitent les audits internes. Vous préparez un projet et voulez savoir s'ils sont en place ? Échangeons sur votre situation.