Livraison par lots avec recette formelle : comment se déroule un projet
Un projet informatique ne se juge pas sur son planning initial mais sur ce qui se passe au quatrième mois, quand une règle oubliée apparaît et que la date de bascule approche. Le découpage en lots et la recette formelle existent pour rendre ce moment gérable plutôt que conflictuel.
2 semaines
de sprint, avec une démonstration du logiciel réel à chaque fin de sprint
PV signé
à chaque jalon : la recette est un acte contractuel, pas un ressenti
Bascule progressive
l'ancien système reste opérationnel tant que le nouveau n'a pas fait ses preuves
La livraison par lots avec recette formelle est le seul dispositif que nous connaissions pour qu'un client sache, à tout instant, ce qui est fini et ce qui ne l'est pas. Elle remplace la question impossible — « où en est le projet ? » — par une question vérifiable : quels lots ont été recettés, et quels cas de test restent ouverts sur le lot en cours ?
Le rythme : des sprints de deux semaines, des jalons contractuels
Deux niveaux de temps coexistent, et les confondre est la première source de malentendus. Le sprint est un rythme de travail interne : deux semaines, une démonstration à la fin, aucun engagement contractuel attaché. Le jalon est un événement contractuel : un lot fonctionnel complet, une recette, un procès-verbal, et une part du périmètre définitivement fermée. Un jalon regroupe généralement deux à quatre sprints.
| Démonstration de fin de sprint | Jalon avec recette formelle | |
|---|---|---|
| Fréquence | Toutes les deux semaines | Toutes les quatre à huit semaines |
| Objet | Montrer le logiciel réel en fonctionnement, corriger la trajectoire | Faire valider un périmètre fonctionnel complet |
| Qui participe | Le référent métier et, quand c'est utile, les utilisateurs concernés | Le référent métier, les utilisateurs testeurs, le signataire |
| Ce qui est produit | Un compte rendu et une liste d'ajustements | Un procès-verbal de recette signé, avec réserves éventuelles |
| Effet contractuel | Aucun | Le lot est réputé conforme ; il déclenche le paiement associé |
| En cas de désaccord | On ajuste dans le sprint suivant | Réserves consignées, corrigées, puis nouvelle recette sur les seuls points ouverts |
Ce qu'est une recette formelle, précisément
« Recette » ne veut pas dire « le client regarde et dit que ça a l'air bien ». C'est une procédure écrite, préparée avant le développement du lot, et exécutée par les personnes qui utiliseront réellement l'outil.
- Un cahier de recette est rédigé au moment du cadrage du lot : la liste des cas à tester, formulés en langage métier, avec le résultat attendu de chacun.
- Un environnement de recette dédié est mis à disposition, alimenté avec vos données réelles anonymisées — pas avec un jeu de démonstration.
- Vos utilisateurs exécutent les cas, un par un, et consignent pour chacun : conforme, non conforme, ou conforme avec remarque.
- Les non-conformités sont qualifiées ensemble en bloquantes ou mineures. Les bloquantes sont corrigées avant signature ; les mineures deviennent des réserves datées.
- Le procès-verbal est signé par une personne habilitée à engager la structure. Il liste les cas passés, les réserves et leur échéance de correction.
- La signature déclenche trois choses : le lot est réputé conforme, la facture du jalon est émise, et le périmètre correspondant est fermé aux discussions ultérieures.
Le rôle du client : un référent métier disponible et habilité
Aucun découpage ne fonctionne sans une personne côté client capable de répondre et de trancher. C'est la condition la plus souvent sous-estimée au moment de signer, et la première cause de dérive quand elle n'est pas tenue. Le référent métier n'a pas besoin d'être technique ; il doit être légitime.
- Disponible : environ une demi-journée par semaine en rythme de croisière, davantage pendant les phases de recette.
- Habilité à arbitrer : décider qu'une demande passe au lot suivant, ou qu'un cas particulier ne sera pas traité, sans devoir convoquer un conseil d'administration.
- Détenteur des règles réelles : celui qui sait pourquoi ce fournisseur a un traitement dérogatoire depuis 2019, pas seulement ce que dit la procédure officielle.
- Capable de mobiliser les testeurs : la recette est exécutée par les utilisateurs, pas par le référent seul ni par nous.
- Unique point d'arbitrage : quatre interlocuteurs qui donnent trois avis contradictoires coûtent plus cher que n'importe quel avenant.
Quand cette condition ne peut pas être tenue — équipe permanente réduite, direction absorbée par l'exploitation —, mieux vaut le dire au cadrage et adapter le découpage : des lots plus petits, plus espacés, avec des recettes plus courtes. Un projet dimensionné pour la disponibilité réelle du client avance plus vite qu'un projet ambitieux qui attend des réponses.
Le run continue pendant le chantier
Une refonte n'arrive jamais sur un terrain vide. Pendant que nous développons, la structure continue de fonctionner : les déclarations de chiffre d'affaires arrivent, les contrats de référencement se renouvellent, l'arrêté annuel tombe à sa date. L'ancien système doit donc rester opérationnel jusqu'à ce que le nouveau ait fait ses preuves sur le processus concerné.
Ordonner les lots par la douleur, pas par l'architecture
Le premier lot traite le processus dont le coût actuel est le plus mesurable — souvent le calcul des bonifications ou les déclarations. Un premier lot technique invisible pour les utilisateurs use le crédit du projet.
Faire tourner le nouveau en parallèle de l'ancien
Sur les processus à enjeu financier, la première campagne réelle tourne deux fois : dans l'outil historique et dans le nouveau. On ne bascule qu'une fois les résultats réconciliés.
Basculer par population d'utilisateurs
Un groupe pilote d'adhérents ou de collaborateurs passe d'abord, sur un périmètre réduit. Les autres suivent une fois les frictions d'usage corrigées.
Éteindre l'ancien système explicitement
La date d'arrêt est décidée et annoncée, pas subie. Tant qu'aucune date n'est posée, les deux outils cohabitent indéfiniment et la double saisie s'installe.
Le critère qui commande tout le découpage
À aucun moment le groupement ne doit se retrouver à dire : on ne peut pas faire l'arrêté cette année, on change de système.
C'est la contrainte qui prime sur toutes les autres, et elle se vérifie lot par lot au moment du cadrage : si le lot en cours devait prendre deux mois de retard, quelle échéance métier serait manquée ? Quand la réponse est « une échéance annuelle non reportable », le lot est redécoupé ou décalé hors de la fenêtre critique. C'est aussi ce qui rend le découpage négociable jusqu'au dernier moment : l'ordre des lots sert le calendrier de la structure, pas l'inverse.
MEKANO est un studio de développement lyonnais. Nous avons livré selon cette méthode la refonte complète du système de gestion d'un groupement lyonnais de plus de 60 sociétés associées — portail associés et fournisseurs, workflows de référencement, déclarations de chiffre d'affaires, moteur de calcul des bonifications de fin d'année, gestion documentaire — au forfait ferme, par lots successifs, en Go, React et PostgreSQL.
Questions fréquentes
- Que se passe-t-il si nous refusons de signer un procès-verbal de recette ?
- Rien de dramatique : c'est prévu. Les non-conformités sont qualifiées ensemble, les bloquantes sont corrigées, et une nouvelle recette est menée sur ces seuls points — pas sur l'ensemble du lot. Le refus de signer ne devient un sujet que s'il porte sur des demandes qui n'étaient pas dans le périmètre du lot : dans ce cas elles sont traitées comme des évolutions, chiffrées et arbitrées, et le lot est signé avec ces réserves inscrites au procès-verbal.
- Combien de temps nos utilisateurs doivent-ils consacrer à la recette ?
- Pour un lot fonctionnel courant, comptez deux à quatre demi-journées réparties sur une semaine, mobilisant deux à quatre utilisateurs représentatifs. Le cahier de recette est fourni : ils exécutent des cas décrits en langage métier, ils ne cherchent pas des bugs au hasard. Sur un lot sensible comme un moteur de calcul, la recette est plus longue parce qu'elle inclut le rejeu d'une campagne passée et la comparaison des montants, ligne à ligne.
- Peut-on modifier le contenu des lots suivants en cours de projet ?
- Oui, tant qu'ils n'ont pas démarré, et c'est l'un des intérêts du découpage. Voir fonctionner le premier lot révèle des priorités qu'aucun atelier n'aurait fait émerger. Le réordonnancement se fait à l'occasion d'un jalon, avec un chiffrage si le contenu global change. Ce que le dispositif interdit, c'est de modifier en continu le lot en cours de développement, qui est précisément la manière la plus fiable de faire déraper un planning.
- Combien de temps sépare la signature du premier lot en production ?
- Sur les projets de gestion que nous menons, le premier lot est généralement en service entre huit et douze semaines après le démarrage, cadrage compris. Ce délai dépend beaucoup moins du volume de développement que du temps nécessaire à écrire les règles réellement appliquées et à obtenir des données d'origine exploitables. Les projets qui prennent du retard le prennent presque toujours avant la première ligne de code, pas après.
- Que devient l'ancien système pendant la refonte ?
- Il reste en service, et c'est une contrainte que nous assumons dans le découpage : aucune échéance métier ne doit être manquée à cause du chantier. Concrètement, cela signifie une période de double fonctionnement sur les processus à enjeu financier, une bascule par population d'utilisateurs, et une date d'extinction décidée explicitement. La double saisie qui s'éternise faute d'avoir fixé cette date est le scénario que nous cherchons d'abord à éviter.
À lire ensuite
Développement au forfait ferme : ce que le modèle fait porter à chacun
Un modèle de facturation n'est pas un détail administratif : il décide qui perd de l'argent quand le projet dérape. Le forfait déplace ce risque vers le prestataire, la régie le laisse chez le client. Les deux sont défendables — à condition de savoir dans quel cas on se trouve avant de signer.
Lire la suiteRéussir la refonte du système de gestion d'un groupement
Un groupement ne refond pas son système parce qu'il est vieux, mais parce qu'un processus critique déborde : l'arrêté des bonifications, la collecte des déclarations, le renouvellement des contrats de référencement. Le projet a donc une date limite réelle, un calendrier annuel qu'il ne peut pas déplacer, et quinze ans de données à reprendre.
Lire la suiteRéversibilité et propriété du code source : ce que la clause doit dire
« Le code source vous appartient » est la phrase la plus répandue et la moins vérifiée des propositions de développement. Entre une cession de droits opposable et une licence d'utilisation habilement formulée, l'écart ne se voit qu'au moment où vous voulez partir — c'est-à-dire trop tard.
Lire la suiteRefonte du système de gestion d'un groupement de 60 sociétés
Un système de gestion qui ne tombe jamais en panne mais que plus personne ne peut faire évoluer coûte plus cher qu'un système qui casse. C'est la situation dans laquelle se trouvait ce groupement lyonnais : tout fonctionnait, rien ne bougeait, et chaque nouveau besoin métier se réglait en dehors de l'outil.
Lire la suiteParlons de votre situation
Trente minutes, sans engagement. Vous repartez avec un avis franc sur la faisabilité, un ordre de grandeur de budget et les prochaines étapes.
Réserver l'appel