Un projet de développement spécifique réussit rarement sur un cahier des charges écrit à plat, puis livré douze mois plus tard : entre-temps, les besoins ont bougé et les utilisateurs découvrent l'outil le jour de la livraison. Notre méthode privilégie l'itération courte, les démonstrations régulières et la mise en production progressive. Cet article détaille ses trois phases, ce que vous devez en attendre à chaque étape et ce que nous attendons de vous. Si vous hésitez encore entre un logiciel standard et du sur-mesure, commencez par SaaS ou sur mesure : comment décider.
Pourquoi un cahier des charges seul ne suffit pas
Le cahier des charges reste indispensable, mais il pose trois problèmes quand il est le seul pilier du projet :
- il décrit des besoins imaginés, que les utilisateurs ne peuvent juger qu'en manipulant un outil réel ;
- il fige un périmètre complet avant la première ligne de code, alors que les priorités évoluent ;
- il repousse la découverte des écarts à la fin du projet, quand les corriger coûte le plus cher.
La méthode MVP (produit minimum viable) inverse la logique : on valide très tôt, sur un périmètre réduit, ce qui apporte de la valeur, puis on enrichit. Le cahier des charges devient un document vivant, construit avec les métiers pendant le cadrage et ajusté à chaque itération.
Les trois phases en un coup d'œil
| Phase | Durée | Objectif | Livrables principaux |
|---|---|---|---|
| 1. Cadrage et spécification | 4 à 6 semaines | Comprendre et prioriser | Cartographie des processus, cas d'usage priorisés, maquette interactive validée |
| 2. MVP | 8 à 12 semaines | Livrer l'essentiel, utilisable | Version fonctionnelle sur environnement pilote, documentation utilisateur |
| 3. Recette et mise en production | Selon le périmètre | Fiabiliser et déployer | Recette par scénarios, super-utilisateurs formés, déploiement progressif |
Phase 1 : cadrage et spécification (4 à 6 semaines)
Le cadrage est la phase la plus rentable du projet, car chaque erreur évitée ici ne sera jamais codée. Elle s'organise autour d'ateliers avec les équipes métier :
- Atelier métier : comprendre le processus tel qu'il est vraiment pratiqué, y compris les contournements et les exceptions ;
- Cartographie des processus : identifier les étapes, les acteurs, les documents échangés et les systèmes existants à relier ;
- Priorisation des cas d'usage : séparer ce qui est indispensable au premier jour de ce qui peut attendre (par exemple avec une priorisation de type MoSCoW) ;
- Maquette interactive : les utilisateurs cliquent dans une version simulée de l'outil et la valident avant tout développement.
À l'issue de cette phase, le périmètre du MVP est arrêté par écrit, ainsi que les critères qui permettront de dire que la version est réussie. Si le projet est piloté par un maître d'ouvrage qui s'appuie sur un accompagnement externe, ce cadrage se prolonge naturellement dans les livrables décrits dans les 5 livrables AMOA d'un projet SaaS.
Phase 2 : le MVP (8 à 12 semaines)
Une version fonctionnelle, déployée sur un environnement pilote, couvre les cas d'usage prioritaires. L'objectif n'est pas d'avoir un outil complet, mais un outil que de vrais utilisateurs peuvent essayer sur de vraies situations. Le travail se déroule ainsi :
- sprints de 2 semaines, chacun terminé par une démonstration aux utilisateurs clés ;
- revue de code et tests automatisés dès le départ, pour que l'outil reste évolutif ;
- documentation utilisateur produite au fil de l'eau, et non rédigée dans la précipitation à la fin ;
- retours des utilisateurs consignés et arbitrés à chaque démonstration : ce qui est ajouté, ce qui est reporté, ce qui est abandonné.
Ce que nous attendons de votre côté
Un projet de développement spécifique ne se délègue pas entièrement. Il suppose un référent métier disponible pour trancher rapidement, des utilisateurs clés présents aux démonstrations et un sponsor capable d'arbitrer entre les priorités. Les retards viennent bien plus souvent de décisions qui tardent que de difficultés techniques.
Phase 3 : recette et mise en production
La recette est le moment où l'outil est confronté à la réalité du terrain. Elle est structurée par scénarios plutôt que laissée au hasard des essais :
- des scénarios couvrant les cas nominaux et les cas limites, rédigés avec les métiers ;
- des critères d'acceptation explicites : chaque scénario est déclaré conforme ou non conforme ;
- un test de reprise des données existantes, si l'outil remplace un fichier ou un ancien logiciel ;
- un suivi des anomalies classées par gravité, avec un arbitrage clair entre ce qui bloque la mise en production et ce qui peut être corrigé ensuite.
Vient ensuite la formation des super-utilisateurs, qui deviennent les relais de leurs collègues, puis un déploiement progressif (par site, par direction ou par équipe). Cette progressivité limite le risque : un problème découvert chez le premier groupe est corrigé avant d'atteindre tous les autres.
Checklist de recette
- Les scénarios de test couvrent chaque cas d'usage du périmètre validé.
- Chaque anomalie est qualifiée (bloquante, majeure, mineure) et suivie jusqu'à sa clôture.
- Les droits d'accès par profil ont été vérifiés.
- La reprise des données a été testée sur un échantillon représentatif.
- Les super-utilisateurs sont formés et la documentation est livrée.
- Un plan de retour en arrière existe en cas de problème à la bascule.
- Le contrat de maintenance et le circuit de support sont définis.
Après la mise en production : évoluer par incréments
Cette méthode permet de livrer un premier outil utilisable en 3 à 4 mois, puis de l'enrichir par incréments successifs tout en observant l'usage réel. Les fonctionnalités reportées pendant le cadrage sont réexaminées à la lumière de ce que les utilisateurs font vraiment de l'outil. C'est cette boucle qui distingue un logiciel vivant d'un livrable qui vieillit dès sa livraison.
La maintenance fait partie du projet dès le départ : correction des anomalies, mises à jour techniques et évolutions sont prévues par contrat, avec un point d'entrée unique pour le support. Un logiciel sur mesure dont personne ne s'occupe après la livraison perd vite sa valeur, quelle que soit la qualité du développement initial.
En pratique
Cette démarche est celle de notre offre de développement spécifique et SaaS métier. Vous avez un processus à outiller et vous voulez savoir par où commencer ? Parlons-en : un échange de cadrage permet de dire si votre besoin relève d'un standard, d'un paramétrage ou d'un développement sur mesure.