Réponse courte. Une application ne se livre pas une fois, à la fin ; elle se livre toutes les deux semaines, et chaque livraison suit le même chemin : un lot écrit avant le code, avec ses scénarios de recette ; des tests automatisés livrés avec chaque fonction et rejoués à chaque changement par une intégration continue sur serveur, qui refuse la livraison avant que le client la voie ; un environnement de recette à sa propre adresse, copie de la production avec des données de test, que le client ouvre sur son téléphone depuis la France ; une démonstration et une acceptation écrite point par point ; puis une mise en production progressive, sans coupure, d'abord un magasin ou une fraction des utilisateurs, avec un retour arrière en une commande et des migrations de base réversibles. Le code, les scripts et les environnements sont au nom de l'entreprise. Vingt-quatre livraisons par an, et le client sait à chaque instant où en est son application.
Ce guide s'adresse au fondateur installé en France qui ne peut pas être dans les locaux du prestataire et veut savoir ce qu'il a le droit d'exiger, à l'entreprise en Algérie qui a vécu la grande livraison de fin de projet et ses trois semaines de pannes, et à celui qui lit « tests et recette » dans un devis sans savoir ce que cela doit contenir. Il ne traite pas de ce qu'on écrit avant le projet, ce que fait le guide sur le cahier des charges, ni des délais globaux, décrits dans le guide sur les délais réels ; il traite de la mécanique qui fait qu'une livraison arrive entière, et qu'une livraison ratée coûte dix minutes et pas un week-end.
Ce que les chiffres disent
La livraison se mesure, et le vocabulaire existe. Le programme de recherche DORA de Google Cloud, qui publie depuis dix ans l'enquête de référence sur la livraison logicielle, définit cinq mesures dans son guide : trois de débit, le délai de changement, « le temps qu'il faut à un changement pour aller du dépôt de code à la production », la fréquence de déploiement, et le temps de rétablissement après un déploiement raté ; deux d'instabilité, le taux d'échec des changements, « la proportion de déploiements qui demandent une intervention immédiate », et le taux de reprise, les déploiements non planifiés faits à cause d'un incident. Ce que cela impose à un client en Algérie ou en France : un prestataire peut être jugé sur ces cinq chiffres, et un devis qui ne permet pas de les mesurer ne décrit pas une méthode de livraison.
Le rapport DORA 2025, publié le 23 septembre 2025 à partir de près de 5 000 réponses de professionnels du monde entier et de plus de cent heures d'entretiens, dit deux choses qui comptent pour 2027 : 90 % des répondants utilisent l'IA au travail, et « contrairement à l'an dernier, nous observons une relation positive entre l'adoption de l'IA et le débit de livraison », mais « l'adoption de l'IA continue d'avoir une relation négative avec la stabilité de la livraison ». Autrement dit, les outils d'IA font écrire plus de code plus vite, et ce code casse plus souvent en production si la méthode de livraison ne suit pas ; le rapport 2024, selon les résumés qui en ont été publiés, voyait déjà la part des équipes très performantes reculer et celle des équipes peu performantes grandir d'une année sur l'autre, un chiffre que nous citons de seconde main. Ce que cela impose : en 2027, la question n'est plus « combien de temps pour écrire la fonction » mais « comment elle arrive en production sans casser ce qui marchait », et c'est ce que ce guide décrit.
Le reste est algérien et ne figure dans aucun rapport : le fondateur à Paris qui ne verra les locaux du prestataire que deux fois dans l'année, décrit dans le guide sur le lancement depuis la France ; le prestataire qui met en ligne par copie de fichiers sur le serveur un jeudi soir ; la recette faite « en regardant » sur l'écran du développeur ; la migration de base lancée en production sans retour possible. Nous n'avons pas de statistique sur ces cas ; nous les rencontrons dans la plupart des projets que nous reprenons, et ce guide est écrit contre eux.
La vie d'une livraison, en six moments
La méthode ne se décrit pas par ses outils mais par ce qui arrive à un lot de travail, de la ligne écrite en semaine 1 au téléphone d'un client un mardi en heures creuses.
Le lot de deux semaines est écrit avant le premier commit : ce qui sera démontré dans quinze jours, en phrases vérifiables, avec pour chaque fonction un scénario de recette, qui fait quoi et ce qu'on doit voir, validé par le client ; c'est le même principe que le guide sur le cahier des charges applique au projet entier, ramené à deux semaines. Le développement avec tests livre chaque fonction avec ses tests automatisés, unitaires pour les règles métier, d'intégration pour les API, de bout en bout sur téléphone pour les parcours ; un changement qui fait échouer un test existant n'entre pas dans la livraison, et c'est la machine qui le dit, pas le client. La revue et l'intégration : un second développeur relit chaque changement, et l'intégration continue construit, teste et déploie sur l'environnement de recette à chaque changement, depuis un serveur, jamais depuis le poste de quelqu'un.
L'environnement de recette est une copie de la production, à sa propre adresse, avec des données de test et les mêmes connecteurs en mode bac à sable, que le client ouvre sur son téléphone depuis la France ; ce qui marche là marchera en production, parce que c'est la même construction. La démonstration et la recette sont le moment qui remplace le voyage : le client exécute les scénarios écrits en semaine 1, sur l'environnement de recette, guidé par une courte vidéo du prestataire, et accepte ou refuse par écrit, point par point ; ce qui est refusé est corrigé ou passe au lot suivant, par écrit. La mise en production progressive se fait sans coupure, en heures creuses, d'abord pour un magasin ou une fraction des utilisateurs, avec quelqu'un qui supervise l'heure qui suit ; si une erreur ou une lenteur monte, le retour arrière est une commande, et la migration de base, faite en deux temps, se renverse avec lui. Le journal des versions reçoit son numéro et sa liste de changements, et le lot suivant est déjà écrit.
La livraison d'une application, en cinq couches
Derrière les six moments, cinq couches, et celle que les devis oublient est la quatrième.
Les exigences et scénarios : le lot écrit, les scénarios de recette et les critères d'acceptation, rédigés avant le code ; c'est contre eux que la livraison est acceptée ou refusée, et sans eux la recette est une impression. Le code et les tests : tests unitaires pour chaque règle métier, tests d'intégration pour chaque API et chaque connecteur, tests de bout en bout sur téléphone pour chaque parcours, et tests d'abus, ceux qui tentent la fuite entre clients décrite dans le guide sur le SaaS multi-tenant ou le pompage de SMS décrit dans le guide sur l'authentification. L'intégration et les environnements : une intégration continue qui construit et teste chaque changement sur serveur, un dépôt au nom de l'entreprise, et trois environnements, recette, préproduction, production, chacun à son adresse.
La mise en production est la couche qui fait qu'une livraison ratée coûte dix minutes : déploiement sans coupure, progressif, migrations réversibles faites en deux temps, ajouter avant et retirer après, et un retour arrière en une commande testé en recette avant chaque mise en ligne ; c'est aussi ce qui permet de mettre à jour cent clients à la fois sans en couper un. La supervision et les retours : erreurs, lenteurs, alertes, retours des utilisateurs et journal des versions, ce qui dit dans l'heure si la livraison a cassé quelque chose, par les mêmes compteurs que le guide sur le tableau de bord décrit pour le gérant. Les outils qui portent ces couches sont ceux que le guide DevOps nomme ; ce guide dit ce que le client en voit.
«Une livraison est un processus répété vingt-quatre fois par an, pas un événement de fin de projet.»
Un exemple chiffré
Un exemple sur une année, avec une mécanique qui ne dépend pas des hypothèses : une application de commerce, un fondateur en France, une équipe en Algérie.
Vingt-quatre livraisons en un an, une toutes les deux semaines, chacune démontrée sur l'environnement de recette et recettée depuis la France avant la mise en ligne ; la première version utilisable est arrivée en semaine 6, pas en mois 6, et le fondateur a fait deux voyages dans l'année au lieu de six. Deux retours arrière : une lenteur sur la page du stock après une migration, retirée en huit minutes, et une règle de remise mal comprise, retirée en six, puis réécrite dans le lot suivant avec son scénario corrigé ; c'est notre hypothèse sur la fréquence, qui se mesure chez vous, et ce qui compte est qu'aucun des deux n'a été vu par plus d'un magasin.
Moins de dix minutes entre le signal et le retour à la version précédente, migration comprise, est la mécanique, pas la chance : la version précédente est toujours prête, la migration a été faite en deux temps et son retour testé en recette, et la commande de retour arrière est la même à chaque livraison. Zéro coupure visible : déploiement sans interruption, en heures creuses, d'abord un magasin pendant une heure, puis tous. Ce que l'exemple montre : avec la grande livraison, les vingt-quatre lots auraient été un seul jour de mise en ligne, tous les scénarios à recetter en même temps, et un retour arrière impossible parce que la version d'avant n'aurait rien eu en commun avec la nouvelle. Les hypothèses à vérifier chez vous : combien de scénarios par lot, combien de temps le client a vraiment pour recetter, et quelle heure creuse chez vos utilisateurs ; la première semaine du projet y répond.
Six choses que le client vérifie à chaque livraison, depuis la France
Six vérifications qui ne demandent ni d'être sur place ni de savoir lire du code, et qu'un client peut exiger à chaque livraison.
Le scénario de recette passe : chaque scénario écrit en semaine 1 est exécuté de bout en bout par le client lui-même, sur l'environnement de recette, depuis son téléphone, avec une courte vidéo du prestataire pour guider ; l'acceptation est écrite point par point, et un refus cite le scénario qui échoue. Les tests automatisés existent : le rapport de tests de l'intégration continue est joint à chaque livraison, et le nombre de tests ne doit pas baisser d'une livraison à l'autre ; un prestataire qui ne peut pas montrer ce rapport n'a pas de tests. Le code est dans votre dépôt : code, scripts de déploiement et documentation sont dans un dépôt Git au nom de l'entreprise, et la livraison est une étiquette de version dans ce dépôt, pas un fichier envoyé ; c'est la protection que le guide sur l'application bloquée chez un développeur disparu recommande.
La migration se renverse : le prestataire montre, chronomètre en main, le retour arrière d'un changement de base sur l'environnement de recette, sans perte de données. Ça marche sur un vrai téléphone : sur des Android d'entrée de gamme, en arabe et en français, sur un réseau bridé, avec capture jointe ; l'environnement de recette ouvert sur le téléphone du client en France ne remplace pas ce test, parce que son téléphone et son réseau ne sont pas ceux de ses utilisateurs, comme le guide sur la PWA et le natif le rappelle. Le journal des versions est tenu : chaque livraison a un numéro, une liste de changements et une date, lisibles par le client ; c'est ce qui permet de dire « depuis la 1.14, le stock est faux » et de revenir à la 1.13 en connaissance de cause.
Six situations qui cassent une livraison
Six situations que nous voyons sur les projets que nous reprenons, et ce que la méthode fait contre chacune.
« Ça marche chez moi » : la démonstration se fait sur le poste du développeur, avec sa base, ses fichiers et sa connexion ; en ligne, rien ne marche pareil. Démonstration et recette uniquement sur l'environnement de recette construit par l'intégration continue, jamais sur un poste. La grande livraison : six mois de travail livrés d'un coup, tout à recetter en même temps, tout qui casse en même temps, et un retour arrière impossible ; un lot toutes les deux semaines, démontré et mis en ligne, avec la première version utilisable en semaine 6. La migration qui ne se renverse pas : le changement de base est fait en production, la livraison échoue, et on ne peut plus revenir sans perdre des données ; migrations en deux temps, ajouter avant, retirer après, et chaque migration avec son retour testé en recette.
La recette sans scénarios : le client « regarde » et dit que c'est bien, et trois semaines plus tard la fonction n'est pas celle attendue ; scénarios écrits avant le code, exécutés point par point, refus écrit avec le scénario qui échoue. Le jeudi soir : mise en ligne avant le week-end, personne pour regarder, et les clients découvrent la panne samedi matin ; mise en production en heures creuses, en semaine, avec quelqu'un qui supervise l'heure qui suit, et jamais la veille d'un jour férié ni pendant le ramadan sans l'avoir planifié. Les tests manuels seulement : chaque nouvelle fonction casse une ancienne que personne n'a repassée ; tests automatisés sur toutes les règles métier, rejoués à chaque changement, et la machine refuse avant le client. Les six ont le même remède : la livraison est un processus répété vingt-quatre fois par an, pas un événement.
«Ce qui est mis en ligne doit pouvoir être retiré en dix minutes, migration comprise ; sinon ce n'est pas une livraison, c'est un pari.»
Vu ailleurs : DORA, et ce qui se transpose
Deux textes publics disent l'essentiel. Le guide des mesures DORA donne le vocabulaire : délai de changement, fréquence de déploiement, temps de rétablissement, taux d'échec, taux de reprise ; ce qui se transpose, c'est que ces cinq chiffres se demandent à un prestataire comme on demande des références, et qu'une équipe qui livre toutes les deux semaines depuis un an peut les donner, alors qu'une équipe qui prépare sa grande livraison n'en a aucun. Le rapport 2025 dit que l'IA accélère l'écriture du code et fragilise la livraison quand la méthode ne suit pas ; ce qui se transpose, c'est que les tests automatisés, l'intégration continue et le retour arrière comptent plus en 2027 qu'en 2024, parce que le code arrive plus vite et doit être retenu plus fermement.
Ce qui ne se transpose pas tel quel : DORA mesure des équipes qui déploient parfois plusieurs fois par jour, pour des produits mondiaux ; une application de commerce en Algérie n'a pas besoin de déployer dix fois par jour, elle a besoin de déployer toutes les deux semaines sans casser, et d'un client en France qui peut le vérifier. Ce que ces textes ne disent pas : quelle heure est creuse chez vos utilisateurs, combien de scénarios tient un lot, et qui, chez vous, a trois jours pour recetter ; la première semaine du projet y répond.
Les règles d'une livraison qui tient
Six règles, écrites la première semaine et relues à chaque livraison. Le lot est écrit avant le code, avec ses scénarios de recette validés par le client ; ce qui n'est pas écrit ne sera pas recetté. Chaque fonction arrive avec ses tests, et un test qui échoue bloque la livraison, par la machine, avant le client. La recette ne se fait que sur l'environnement de recette, construit par l'intégration continue, jamais sur un poste ni en production. Rien ne part en production sans acceptation écrite, point par point, et ce qui est refusé passe au lot suivant, par écrit. Toute mise en production est progressive et réversible : heures creuses, un magasin d'abord, retour arrière en une commande, migrations en deux temps, jamais la veille d'un jour férié. Le code, les scripts, les environnements et les comptes sont au nom de l'entreprise, et la livraison est une étiquette dans son dépôt.
Une septième règle porte sur le devis : « tests et recette » n'est pas une méthode, c'est une phrase ; la méthode s'écrit « un lot démontré toutes les deux semaines sur un environnement de recette accessible au client ; tests automatisés livrés avec chaque fonction, rapport joint ; acceptation écrite avant toute mise en production ; mise en production progressive avec retour arrière en moins de quinze minutes, migration comprise, démontré à chaque livraison ; dépôt et environnements au nom du client », et elle se vérifie dès la première livraison. Un devis qui chiffre « la recette » comme une phase finale de trois semaines a chiffré la grande livraison, avec ce qu'elle coûte ensuite, décrit dans le guide sur la vie d'une application.
Six projets, ce qu'on livre et ce qu'on recette
Six projets que nous livrons souvent, et pour chacun ce que contient un lot de deux semaines et ce que le client recette.
- L'application de terrain hors ligne, décrite dans le guide dédié. Recette en mode avion sur un vrai téléphone : saisir, couper le réseau, rallumer, vérifier que rien n'est perdu ni doublé ; mise en production magasin par magasin.
- Le portail ou la marketplace. Recette des parcours de commande et de paiement en bac à sable, depuis la France ; mise en production en heures creuses avec une fraction des visiteurs d'abord.
- L'agent IA sur WhatsApp, décrit dans le guide dédié. Recette sur un numéro de test avec les scénarios de conversation écrits, passage à l'humain compris ; mise en production pour un lot de clients d'abord.
- L'intégration avec la comptabilité, décrite dans le guide dédié. Recette par le comptable sur des écritures de test ; premier flux deux semaines en parallèle de la saisie avant qu'on l'arrête.
- Le SaaS multi-tenant. Recette sur un tenant de test, test de fuite entre tenants joint à chaque livraison ; mise en production par vagues de clients, migrations réversibles démontrées.
- Le tableau de bord du gérant. Recette des dix chiffres contre ceux du comptable sur un mois ; mise en production sans toucher aux caisses, avec le rapport du lundi maintenu jusqu'à l'acceptation.
Le lot de deux semaines, jour par jour
Le calendrier est celui d'un lot de quatorze jours, qui se répète vingt-quatre fois dans l'année, et dont trois jours appartiennent au client.
Le jour 0 à 1 écrit le lot et ses scénarios de recette, validés par le client avant le premier commit ; c'est le jour qui décide si la recette sera une vérification ou une impression. Les jours 1 à 8 développent, chaque fonction avec ses tests, l'intégration continue construisant et testant à chaque changement et mettant à jour l'environnement de recette chaque jour, pour que le client puisse regarder avant la fin s'il le veut. Le jour 8 à 9 est la revue et le gel : relecture par un second développeur, plus de nouvelle fonction après le jour 9, seulement des corrections. Les jours 9 à 11 appartiennent au client : trois jours pour exécuter les scénarios depuis la France, sur son téléphone, et accepter ou refuser par écrit, point par point.
Le jour 11 à 12 corrige les points refusés et les fait re-recetter ; ce qui ne tient pas dans le délai passe au lot suivant, par écrit, et ne part pas en production. Le jour 12 à 13 est la mise en production progressive, en heures creuses, un magasin ou une fraction d'abord, avec le retour arrière prêt et quelqu'un qui supervise. Le jour 13 à 14 supervise la version, recueille les retours, met à jour le journal des versions et écrit le lot suivant. Sur l'année, ce cycle est ce qui remplace quatre des six voyages du fondateur décrits dans le guide sur le lancement depuis la France : les deux qui restent servent à rencontrer les clients, pas à vérifier le prestataire.
Ce qui fait échouer une livraison
Les projets que nous reprenons ont presque toujours échoué à la livraison pour l'une de ces raisons.
- La grande livraison. Six mois sans rien mettre en ligne, puis tout d'un coup ; tout casse, et rien ne se renverse.
- La démonstration sur le poste du développeur. Ce que le client a vu n'existe nulle part ailleurs.
- Pas de tests automatisés. Chaque livraison casse une fonction ancienne ; le client devient le testeur, à distance, sans scénarios.
- La migration irréversible. La base a changé, la livraison a échoué, et la seule issue est de corriger en production, la nuit.
- La mise en ligne du jeudi soir. Personne ne regarde, et les clients découvrent la panne le samedi.
- Le dépôt chez le prestataire. La livraison est un fichier envoyé ; le jour où le prestataire ne répond plus, la version d'avant est perdue.
- Le client qui n'a pas trois jours. La recette est signée sans être faite ; le refus arrive un mois plus tard, quand le lot suivant a déjà bâti dessus.
Questions fréquentes
Les questions que nous recevons de fondateurs installés en France, de gérants en Algérie et d'équipes qui reprennent un projet.
- Je suis en France. Comment vérifier le travail sans me déplacer ?
- Par l'environnement de recette, à sa propre adresse, que vous ouvrez sur votre téléphone, et par les scénarios écrits avant le code que vous exécutez vous-même tous les quinze jours ; le rapport de tests, l'accès au dépôt Git et le journal des versions complètent. Les deux voyages de l'année servent à rencontrer vos clients, pas à surveiller le prestataire.
- Toutes les deux semaines, ce n’est pas trop souvent ?
- C'est ce qui rend chaque livraison petite, donc recettable en trois jours et réversible en dix minutes. Une livraison tous les six mois est grande, donc impossible à recetter entièrement et impossible à renverser. Le rythme se tient si le lot est écrit avant le code et si les tests sont automatisés.
- Que se passe-t-il si la mise en production casse quelque chose ?
- La version précédente est toujours prête, la migration de base a été faite en deux temps et son retour testé en recette, et le retour arrière est une commande : moins de dix minutes, et seul le premier magasin ou la première fraction d'utilisateurs a vu le problème. Le lot est ensuite corrigé et re-recetté avant de repartir.
- Comment savoir si les tests existent vraiment ?
- Le rapport de tests de l'intégration continue est joint à chaque livraison, avec le nombre de tests et leur résultat, et ce nombre ne doit pas baisser ; le prestataire peut aussi montrer, en recette, un changement volontairement faux refusé par la machine. Un prestataire qui ne peut montrer ni l'un ni l'autre n'a pas de tests.
- Peut-on mettre en ligne pendant le ramadan ou avant un jour férié ?
- Pas la veille d'un jour férié, et pendant le ramadan seulement aux heures creuses réelles de vos utilisateurs, qui ne sont pas celles du reste de l'année ; la règle est qu'une mise en production se fait quand quelqu'un peut superviser l'heure qui suit et que vos utilisateurs sont peu nombreux.
- Que doit contenir le devis sur ce point ?
- Un lot démontré toutes les deux semaines sur un environnement de recette accessible au client ; des tests automatisés livrés avec chaque fonction et leur rapport ; une acceptation écrite avant toute mise en production ; une mise en production progressive avec retour arrière démontré ; le dépôt et les environnements au nom de votre entreprise. Un devis qui chiffre la recette comme une phase finale de trois semaines décrit la grande livraison.