Du besoin au produit livré : ma méthodologie de travail

« Il me faut un site », « on voudrait automatiser nos fichiers », « notre outil ne fait plus ce qu’on veut » : un projet commence presque toujours par un besoin mal formulé. Entre cette phrase et un produit livré, validé et mis en production, il y a une suite d’étapes que j’ai appris à rendre explicites. Cet article les décrit dans l’ordre, avec les documents qui les accompagnent (devis, contrat, avenant), puis explique comment je peux intervenir : sur une étape, sur une partie du périmètre, ou sur l’ensemble.

Vue d’ensemble du cycle de livraison

Voici le déroulé complet, du premier échange à la vie du produit :

1. Besoin exprimé (souvent flou) ;
2. Analyse du besoin : reformulation, questions, objectifs ;
3. Besoin fonctionnel structuré, puis spécifications fonctionnelles et cahier de recette ;
4. Spécifications techniques ;
5. Décomposition en tâches, planifiées en lots de livraison datés ;
6. Réalisation par l’équipe technique, avec validations du client au fil de l’eau ;
7. Validation par le product owner, lot par lot ;
8. Livraison en préproduction puis recette fonctionnelle ;
9. Validation définitive par le client, qui déclenche le paiement du solde et la mise en production ;
10. Après la livraison : corrections, nouvelles versions, maintenance.

1. De la phrase floue au besoin structuré

La première étape est un travail d’analyse métier. L’analyste (business analyst) écoute, reformule, pose des questions : qui utilise l’outil, pour faire quoi, avec quelles données, avec quelles contraintes, et surtout quel résultat serait considéré comme un succès. Il fait aussi émerger ce que personne n’a dit parce que c’est « évident » pour ceux qui le vivent. Le résultat est un besoin fonctionnel structuré : des objectifs, un périmètre, des cas d’usage et un ordre de priorité entre l’indispensable et le souhaitable.

C’est l’étape la moins visible et la plus rentable : une erreur de compréhension corrigée ici coûte une conversation ; la même erreur découverte à la recette coûte du développement refait. J’en parle plus longuement dans spécifications et analyse du besoin : pourquoi elles comptent.

2. Les spécifications fonctionnelles, et le cahier de recette dès le départ

Le besoin structuré est ensuite traduit en spécifications fonctionnelles : pour chaque fonctionnalité, une description, une priorité et un critère d’acceptation, c’est-à-dire la façon dont on constatera qu’elle fonctionne. Les éléments que le client doit fournir (textes, images, accès) et les composants tiers utilisés y figurent aussi, de même que ce qui est volontairement exclu.

Je rédige le cahier de recette dès cette étape, et non à la fin. Il liste les scénarios de test qui permettront de dire « c’est conforme ». Ce choix a deux effets : il oblige à rendre chaque exigence vérifiable, et il fixe le périmètre. Ce qui n’est ni dans les spécifications ni dans le cahier de recette n’est pas dans le projet, sauf accord écrit.

3. Les spécifications techniques

Les spécifications techniques répondent à la question « comment ? » : architecture, technologies et versions, hébergement, services tiers et API, sécurité, données personnelles. Elles sont destinées à l’équipe technique et au futur exploitant du produit. Le client n’a pas à les maîtriser, mais il doit en connaître les conséquences : un hébergement à prévoir, un abonnement à souscrire, une contrainte de compatibilité.

4. Découper en tâches et planifier en lots datés

Le projet est découpé en tâches courtes et vérifiables, selon une logique agile : on avance par petits incréments plutôt que par un grand livrable final. Ces tâches sont regroupées en lots de livraison, chacun avec une date prévisionnelle. Le planning identifie aussi qui doit fournir quoi et quand : remise des contenus et des accès, validation des maquettes ou des spécifications, livraison en recette, fin de la recette, mise en production.

Les dates sont des repères tenus tant que chacun remplit sa part : si le client tarde à fournir un contenu ou une validation, le planning se décale d’autant. Je préfère le dire dès le début plutôt que de le découvrir en cours de route.

5. Réalisation, validations au fil de l’eau et retours des développeurs

Pendant la réalisation, le client n’est pas écarté jusqu’à la livraison. Les livrables intermédiaires (maquettes, arborescence, spécifications, prototypes) lui sont soumis pour validation écrite, dans un délai convenu, avec un nombre défini de cycles de corrections. Ce qui est validé ne se remet pas en cause sans modifier le périmètre.

De leur côté, les développeurs remontent en continu ce qu’ils constatent : une spécification ambiguë, une contrainte technique imprévue, un risque sur le planning. Ces retours sont traités tout de suite, par la voie du product owner, au lieu de s’accumuler jusqu’à la fin. Le product owner valide ensuite chaque lot livré par l’équipe technique, avant qu’il soit présenté au client.

6. Livraison en préproduction et recette fonctionnelle

Chaque lot est livré dans un environnement de préproduction, distinct de la production, lorsque la nature du projet le permet. Le client y fait sa recette fonctionnelle en suivant le cahier de recette. Les anomalies qu'il relève sont qualifiées d’un commun accord :

• bloquante : une fonctionnalité essentielle est inutilisable et rien ne permet de la contourner ;
• majeure : une fonctionnalité est dégradée, mais un contournement existe ;
• mineure : sans incidence significative sur l’usage (affichage, libellé).

Les anomalies bloquantes et majeures sont corrigées puis relivrées pour une nouvelle vérification. Les anomalies mineures peuvent faire l’objet de réserves, levées après coup. La recette se formalise par un procès-verbal : prononcée sans réserve, avec réserves mineures, ou refusée.

7. Validation définitive, paiement et mise en production

La validation définitive par le client clôt la phase de réalisation. Elle déclenche le règlement du solde et la mise en production, à une date convenue, après une sauvegarde de l’existant. Les codes sources, la documentation et les accès d’administration sont remis au client. Les noms de domaine, hébergements et comptes tiers sont souscrits au nom du client, qui en reste titulaire. Les conditions de paiement figurent dans le devis et le contrat ; les montants dépendent de chaque projet et sont établis sur devis.

8. Et après la livraison ?

• Corrections hors cadre : une demande qui sort du périmètre validé n’est pas une anomalie. Elle est chiffrée dans un devis complémentaire ou formalisée par un avenant qui précise ce qui est ajouté, modifié ou retiré, l’incidence sur le prix et le planning. Un besoin plus large donne lieu à un nouveau contrat.
• Nouvelles fonctionnalités et versions suivantes : elles suivent le même cycle, en repartant du produit existant.
• Maintenance à long terme : un contrat de services récurrents décrit précisément ce qui est souscrit : maintenance corrective, mises à jour de sécurité, sauvegardes, supervision, gestion de l’hébergement et du nom de domaine, suivi du référencement, petites évolutions. Un état des lieux initial fixe ce qui est pris en charge.

À défaut de contrat de services récurrents, les mises à jour de sécurité et le suivi du produit restent à la charge du client. Je le précise toujours à la recette, pour éviter qu’un site ne vieillisse sans que personne s’en occupe.

Les documents qui jalonnent le projet

Document	À quoi il sert
Devis	Décrire la prestation, les étapes, le mode de facturation et les conditions, avant tout engagement
Contrat de réalisation	Cadrer un projet de développement ou d’automatisation : objet, cahier des charges, planning, recette, propriété intellectuelle
Avenant	Modifier un contrat en cours : périmètre, planning, prix
Contrat de services récurrents	Organiser la maintenance et le suivi après la mise en production

Comment je peux intervenir

Un projet n’a pas besoin d’être confié en entier. Je peux intervenir :

• sur l’amont seulement : analyse du besoin, spécifications, cahier de recette, éventuellement pour que vous confiiez ensuite la réalisation à une autre équipe ;
• sur la réalisation à partir de spécifications que vous avez déjà ;
• sur la recette et le suivi d’un prestataire, pour vérifier que le livré correspond au demandé ;
• sur l’ensemble du cycle, du besoin flou à la maintenance.

Dans tous les cas, le même principe s’applique : un périmètre écrit, des validations tracées et un critère clair pour dire que le travail est terminé. Le détail de ma façon de travailler est aussi présenté sur la page comment je travaille.