Refonte de site : remplacer le cahier des charges figé par des tranches testables
Refonte de site : remplacer le cahier des charges figé par des tranches testables
Un cahier des charges reste utile pour cadrer une création ou une refonte de site. Le problème commence lorsqu’il essaie de figer, avant le premier test, toutes les pages, toutes les fonctions et tous les comportements du futur produit.
Une longue liste peut rassurer au moment de signer. Elle ne prouve pas que les éléments seront construits dans le bon ordre, compris de la même manière ou validés avant que les reprises deviennent coûteuses.
Pour une TPE ou une PME, l’alternative n’est pas de travailler sans cadre. Il s’agit de séparer ce qui doit rester ferme de ce qui doit évoluer, puis de transformer le projet en tranches que l’on peut réellement observer, tester et recetter.
Le cahier des charges doit cadrer la décision, pas prédire chaque écran
France Num rappelle qu’un cahier des charges sert à formaliser les objectifs, les cibles, les contraintes et le périmètre. Il permet aussi de comparer les prestataires et de poser une base contractuelle.
Ces fonctions restent essentielles. Trois blocs doivent être suffisamment clairs avant de commencer.
1. Le résultat métier recherché
Le projet doit nommer l’action que le site doit améliorer : obtenir une demande qualifiée, vendre un produit, réduire les sollicitations répétitives, donner accès à un service ou faciliter une opération interne.
« Moderniser notre image » peut être une intention. Ce n’est pas encore un résultat que l’on peut recetter.
2. Les contraintes non négociables
Budget, calendrier, identité, accessibilité, sécurité, données personnelles, outils à conserver, responsabilités et conditions de mise en ligne doivent être explicites. Leur évolution peut avoir une conséquence contractuelle ou opérationnelle.
3. La façon de décider et de valider
Qui tranche lorsqu’un choix bloque ? Qui fournit les contenus ? Qui valide une page, un parcours ou une fonction ? Quelle preuve permet de considérer un élément comme terminé ?
Sans cette organisation, même une spécification détaillée laisse les décisions importantes circuler entre les réunions, les emails et les messageries.
Une liste de fonctionnalités ne donne pas un ordre de construction
Un portail client peut prévoir des projets, des jalons, des notifications, des fichiers, une messagerie et une continuité avec le CMS. Écrits sur une même page, ces six éléments semblent avancer ensemble.
En réalité, chacun dépend de règles différentes. Il faut définir les droits d’accès avant d’exposer des données. Il faut disposer d’un projet et de jalons fiables avant de calculer une progression. Il faut une mise à jour réelle avant d’envoyer sa notification. Il faut un flux validé avant de promettre sa continuité après livraison.
Une tranche testable prend un seul résultat utile et traverse les couches nécessaires pour le rendre observable. Elle ne livre pas « un peu de base de données », puis « un peu d’interface ». Elle permet à un utilisateur identifié d’accomplir un geste complet dans un périmètre réduit.
DesignGouv recommande précisément de découper et prioriser les travaux, puis de concevoir, tester et développer le service de manière itérative. L’objectif n’est pas d’abandonner la vision globale. C’est d’éviter que toutes les hypothèses soient validées à la fin.
Exemple réel : l’ordre produit du Dashboard ONORA
Le plan produit du Dashboard ONORA contient quatre tranches :
- Project Cockpit V1 ;
- mises à jour et notifications ;
- actions client et fichiers ;
- continuité avec le CMS après livraison.
La première tranche possède un résultat précis. Un membre ONORA autorisé doit pouvoir créer un projet, définir ses phases et ses jalons, publier une mise à jour et conserver une trace des changements. Un client autorisé doit voir uniquement son projet, sa phase actuelle, une progression dérivée des jalons, la prochaine étape et les dernières mises à jour.
La recette doit aussi vérifier qu’un utilisateur d’une autre organisation ne peut pas accéder au projet, que les parcours fonctionnent sur ordinateur et mobile et que les fonctions financières existantes ne régressent pas.
Cette décision documentée est une preuve de méthode, pas la preuve que la fonction est déjà livrée. Les tranches suivantes ne sont pas présentées comme acquises et ne doivent pas être développées en parallèle tant que la première n’est pas recettée.
Cette discipline évite de produire un écran destiné à rassurer ou à communiquer alors que le geste principal ne fonctionne pas encore.
Écrire les critères de recette avant le développement
Une fonction comme « espace client » ou « suivi de projet » reste trop large pour être validée. Avant le développement, sa première tranche doit répondre à cinq questions.
- Qui agit ? Un utilisateur, avec un rôle et des droits définis.
- Quel geste accomplit-il ? Une action complète, formulée avec un verbe.
- Quel résultat observe-t-il ? Une information, un changement d’état ou une confirmation vérifiable.
- Qu’est-ce qui est exclu ? Les fonctions qui attendront une autre tranche.
- Quels contrôles doivent réussir ? Cas nominal, erreurs, permissions, mobile, accessibilité et non-régression selon le risque.
L’événement publié par La French Tech Est le 28 août 2026 résume bien le risque inverse : spécifications ambiguës, incompréhensions entre équipes, tests tardifs et développements à reprendre.
Un critère de recette réduit cette ambiguïté parce qu’il décrit une sortie observable. « Prévoir des notifications » est une intention. « Lorsqu’une mise à jour importante est publiée, le client autorisé la voit dans sa timeline et reçoit une notification sans donnée sensible » peut être testé.
Un format simple pour la première tranche
Avant de lancer une refonte, une page peut suffire pour décrire la première tranche :
- Objectif métier : ce que l’entreprise cherche à améliorer.
- Utilisateur principal : la personne qui accomplira le geste.
- Point de départ : la situation ou l’événement qui déclenche le parcours.
- Résultat attendu : ce qui doit être visible ou utilisable à la fin.
- Périmètre inclus : les pages, données et comportements nécessaires.
- Périmètre exclu : ce qui est volontairement reporté.
- Critères de recette : scénarios et contrôles à réussir.
- Responsable de la validation : la personne qui prononce l’acceptation.
Le reste ne disparaît pas. Il rejoint un backlog priorisé. Son ordre peut changer lorsque la première tranche révèle une contrainte, un besoin utilisateur ou une dépendance mal comprise.
Ce que cette méthode change pour une TPE ou une PME
Le dirigeant ne paie plus uniquement pour une liste de fonctions annoncées. Il peut demander quel résultat sera testable en premier, à quelle date, par qui et avec quels critères.
Le prestataire dispose d’un cadre plus honnête pour signaler une hypothèse ou un changement. Le client peut arbitrer plus tôt, avec une conséquence visible sur le périmètre, le budget ou le calendrier.
Le cahier des charges conserve donc sa place. Il fixe la destination, les contraintes et les responsabilités. Les tranches testables organisent le trajet et obligent chaque étape à produire une preuve.
Une refonte devient plus lisible lorsque le premier engagement n’est pas « toutes les fonctionnalités sont prévues », mais « voici le premier résultat complet que vous pourrez réellement recetter ».
