Vous envoyez un fichier de contacts dans votre nouvel outil. Une ligne est incomplète, l'import s'arrête et aucun message n'explique le problème. Vous demandez une correction. Le développeur répond que la gestion de ce cas n'était pas prévue et propose de la facturer.
Un devis supplémentaire peut être justifié pour un besoin qui s'élargit. Pour un défaut du fonctionnement commandé, demandez d'abord pourquoi la correction sortirait de l'engagement initial. Vous devez examiner le périmètre convenu, la cause du problème et les conditions de prise en charge.
Le principe à poser dans un forfait est simple : le développeur prend en charge les erreurs techniques prévisibles de la fonctionnalité qu'il réalise. Après livraison, vérifiez aussi la période de correctifs incluse et les engagements de maintenance, s'il y en a. Vous décidez ensemble des règles métier. Quand vous ajoutez un nouveau besoin, vous discutez de son prix et de son effet sur le calendrier.
Un devis au forfait précise ce qui sera livré
Appliquez à vos tickets de développement la lecture d'un devis de cuisine, où ce qui manque se voit facilement : voici 4 situations à distinguer.
Dans votre cuisine
Dans votre logiciel
De la cuisine au logiciel : les mêmes distinctions à faire dans le devis
Une demande trop vague
- Cuisine
-
« Refaire la cuisine. »
- Logiciel
-
« Importer des contacts. »
Le professionnel et vous pouvez imaginer des résultats différents.
Un résultat défini
- Cuisine
-
- Îlot central
- Plan de travail en pierre
- Électroménager inclus
- Logiciel
-
- Fichier CSV
- Doublons reconnus par e-mail
- Lignes incorrectes signalées
Le devis et les tickets précisent ce que vous achetez.
Un défaut à corriger
- Cuisine
-
Une porte du meuble installé ne ferme pas.
- Logiciel
-
Un fichier vide fait planter l’import.
Gérer ce défaut fait partie du travail de réalisation.
Un besoin ajouté
- Cuisine
-
Abattre une cloison prévue pour rester en place.
- Logiciel
-
Importer aussi les entreprises et enrichir les contacts.
Le périmètre change : vous convenez du prix avant l’ajout.
Le forfait s'appuie sur des tickets et des critères d'acceptation
Un bon devis au forfait s'appuie sur un backlog, une liste de tickets classés par priorité. Chaque ticket est une fiche qui décrit un travail à réaliser. Vous pouvez joindre cette liste au devis ou la référencer dans une version datée, pour conserver le contenu sur lequel vous vous êtes mis d'accord.
Retrouvez ces 4 informations dans le périmètre du forfait :
- Le résultat attendu. Chaque ticket décrit un travail utile, comme importer des contacts sans les ressaisir.
- La priorité. Vous savez ce qui doit arriver d'abord et ce qui dépend d'une autre fonctionnalité.
- Les critères d'acceptation. Ces conditions observables permettent de vérifier que le résultat livré correspond au besoin convenu.
- Ce qui est compris dans le prix. Les tickets du forfait sont identifiés ; les idées pour une prochaine version restent séparées.
Pour l'import illustré, le nom et l'adresse e-mail sont obligatoires ; l'adresse permet de reconnaître les doublons. Voici comment le besoin peut devenir un ticket vérifiable.
Le mauvais ticket
Insuffisant pour développer
« Importer des contacts »
Permettre au responsable commercial d’importer ses contacts pour éviter la ressaisie.
- Pas précis
Le format du fichier et la règle sur les doublons restent à deviner.
- Pas de critères d’acceptation
Aucun résultat observable ne permet de dire que le ticket est terminé.
- Pas borné
Ni volume maximal, ni erreurs à gérer, ni exclusions ne sont indiqués.
Sans ces repères, chacun peut juger à sa façon si le ticket est terminé.
Le bon ticket
Précis · vérifiable · borné
Importer un CSV de contacts sans doublons
Le nom et l’e-mail sont obligatoires. L’e-mail sert à reconnaître un contact déjà présent.
Les 5 critères d’acceptation
- Format et volume
Un CSV conforme au modèle fourni est accepté jusqu’à 1 000 lignes. Un fichier vide, illisible ou dépassant cette limite est refusé avec une explication.
- Résultat de l’import
Avec 20 contacts nouveaux, distincts et valides, 20 contacts sont créés et consultables.
- Ligne incorrecte
Une ligne sans e-mail est refusée et signalée avec le champ à corriger. Les autres lignes valides sont importées.
- Doublon
Si l’e-mail existe déjà, le contact existant est conservé sans créer de doublon.
- Droits d’accès
Un compte sans autorisation ne peut importer aucun contact.
Hors périmètre : importer des entreprises et enrichir automatiquement les contacts.
Vous pouvez discuter ces critères pendant le cadrage, avant d'accepter le devis. Pour les doublons, conserver le contact existant et fusionner automatiquement ses données avec celles du fichier sont des comportements différents. Le choix doit être convenu, car il change le travail et les résultats obtenus.
Pour les lignes incorrectes, le ticket choisit d'importer les autres et de signaler celles à corriger. Vous pouvez aussi choisir de refuser tout le fichier. Le développeur doit faire apparaître cet arbitrage métier pendant le cadrage, puis prévoir les contrôles qui rendent le comportement fiable.
Vous devez pouvoir relier le chiffrage à ces tickets. Sans ce détail, un montant ne vous dit ni ce que vous achetez ni comment vous pourrez vérifier la livraison. Le plan de développement doit donc fournir les tickets qui rendent le travail à chiffrer explicite.
Les erreurs techniques font partie du travail du développeur
Vous n'avez pas à deviner toutes les manières dont un fichier peut être incorrect. Un fichier vide ou une ligne mal formée sont des situations prévisibles lorsqu'on développe un import. Leur prise en charge doit faire partie de la réalisation de cette fonctionnalité.
Gérer une erreur peut consister à refuser le fichier et à expliquer pourquoi. Cela n'implique pas de réparer automatiquement toutes ses données. Si le prestataire présente ce contrôle comme une nouvelle fonction, demandez pourquoi il n'était pas compris dans la réalisation de l'import.
Les cas limites mettent le fonctionnement à l'épreuve, comme une donnée absente ou une action répétée. Le développeur choisit les tests adaptés, même lorsque l'IA aide à écrire le code. En tant que sponsor, vous portez le projet côté client et validez les résultats métier. Vous pouvez confier ces essais à une personne qui connaît votre activité.
Qui fait quoi sur l’import de contacts
Tester le fonctionnement métier
- Responsable
- Sponsor
- Dans l’import de contacts
- Importer les 20 contacts, les retrouver et vérifier qu’ils sont utilisables dans le parcours prévu.
Décider des règles métier
- Responsable
- Sponsor, avec le développeur
- Dans l’import de contacts
- Le développeur explique les choix possibles pour les doublons. Le sponsor choisit de conserver le contact existant ; le développeur traduit ce choix en critères d’acceptation.
Gérer les erreurs prévisibles
- Responsable
- Développeur
- Dans l’import de contacts
- Refuser un fichier vide ou illisible avec une explication. Signaler une ligne sans e-mail et importer les autres lignes valides, comme convenu dans le ticket.
Tester les limites et les droits
- Responsable
- Développeur
- Dans l’import de contacts
- Vérifier le comportement à la limite de 1 000 lignes et au-delà, ainsi que le refus d’importer pour un compte non autorisé.
Vérifier les fonctions existantes
- Responsable
- Développeur
- Dans l’import de contacts
- Après l’ajout de l’import, vérifier que la création et la modification manuelles d’un contact fonctionnent toujours.
Corriger puis valider à nouveau
- Responsable
- Développeur, puis sponsor
- Dans l’import de contacts
- Si le même fichier crée des doublons, le développeur corrige et ajoute un test pour éviter leur retour. Le sponsor refait l’essai et confirme le résultat métier.
« Ce n'était pas écrit » ne devrait donc pas clore la discussion. Demandez si le problème relève d'une règle métier à préciser ou du traitement technique nécessaire pour faire fonctionner la règle convenue. Le ticket aide à départager les situations ; il ne sert pas à transformer chaque oubli de formulation en supplément.
Une nouvelle fonction peut justifier un nouveau devis
Vous essayez l'import de contacts et découvrez qu'il serait utile d'importer aussi les entreprises. Vous souhaitez ensuite que le logiciel retrouve automatiquement leur secteur d'activité et enrichisse les contacts. Ces idées peuvent avoir de la valeur, mais elles élargissent le besoin décrit dans le ticket.
Importer des entreprises demande de définir leurs informations et leurs liens avec les personnes. L'enrichissement automatique ajoute une source de données à choisir, parfois payante, et des règles pour décider quelles informations conserver. Le développeur a de nouveaux comportements à construire et à vérifier.
Vous pouvez alors accepter un devis complémentaire, reporter ces idées ou remplacer un autre élément du lot, avec l'accord du prestataire. Un lot désigne ici le groupe de fonctionnalités que vous avez convenu de livrer ensemble. Les changements doivent apparaître dans le backlog pour que le prix et la livraison restent compréhensibles.
La priorité organise l'ordre du travail ; elle ne change pas à elle seule le contenu acheté. Un ticket secondaire inclus dans le forfait reste dans le périmètre tant que vous n'avez pas convenu de le retirer ou de le remplacer. Le même principe évite de confondre une idée notée pour plus tard avec une fonction déjà commandée.
La recette rend les désaccords visibles au fil des livraisons
La recette consiste à vérifier que ce qui est livré répond au besoin convenu. Vous désignez côté client une personne qui connaît l'activité et qui essaie les versions au fil du projet. Elle s'appuie sur les critères des tickets et sur la liste des changements livrés.
Testez sur la préproduction, une installation destinée aux essais, séparée du service utilisé au quotidien. Le développeur doit prévoir des comptes et des données de test adaptés, avec un repère pour la version livrée. Vous vérifiez les résultats métier sans avoir à inventer les contrôles techniques du prestataire.
Pour le ticket présenté, importez le même fichier de 20 contacts à 2 reprises. Si vous obtenez 40 contacts, le critère sur les doublons échoue. Vous pouvez montrer l'écart avec la règle convenue. Si vous demandez plutôt d'ajouter automatiquement des informations absentes du fichier, vous discutez d'une évolution.
Vous devez aussi essayer le lot dans son ensemble : importer les contacts, les retrouver et les utiliser dans le parcours prévu. Le développeur vérifie de son côté que ses modifications n'ont pas cassé des fonctions qui marchaient auparavant. Ces contrôles de non-régression complètent votre recette métier.
Des feedback loops courtes pour maîtriser le coût des corrections
De bons tickets n'empêchent pas de découvrir les problèmes trop tard. Pour mieux maîtriser la qualité et le coût, visez une feedback loop courte : un petit lot parcourt toutes les étapes du développement, jusqu'à la production et aux retours sur son utilisation. Le pilotage définit ce qu'il faut réaliser et comment. Pendant le build, le développeur réalise et vérifie les tickets convenus, puis livre après votre recette métier.
Le délai à réduire comprend aussi l'attente entre les étapes. Un développement terminé rapidement, puis laissé sans recette, retarde la découverte des écarts. Prévoyez la disponibilité de la personne qui teste côté client au moment où le lot sera prêt.
Une feedback loop complète sur un petit lot
Le délai à raccourcir va du besoin au retour sur le logiciel livré.
-
Pilotage
Définir
Besoin, priorité et critères d’acceptation
-
Pilotage
Planifier
Choix techniques et petit lot à réaliser
-
Build
Développer
Réaliser les tickets du lot convenu
-
Build
Vérifier
Tests techniques et relecture du code
-
Client
Faire la recette
Essayer le lot en préproduction
-
Build · après validation
Livrer et suivre
Mise en production et suivi des retours
Les retours d’usage alimentent les prochains tickets.
Un critère n’est pas respecté ?
Le développeur corrige et vérifie ; le client refait la recette avant la mise en production.
Vous pouvez organiser ce cycle dans une software factory qui relie le cadrage, les contrôles et la livraison avec l’IA. Le décryptage suit un tunnel de paiement pour montrer comment coordonner plusieurs applications et où placer les vérifications humaines.
Avec un petit lot, vous pouvez repérer une règle mal comprise avant de construire plusieurs fonctionnalités qui en dépendent. Vous limitez ainsi le travail à reprendre, en obtenant des retours plus tôt sur chaque lot.
Le même enchaînement figure dans le schéma de la méthode par parcours, dans le décryptage sur le développement mobile avec l'IA.
Avant d'accepter un devis de correction
Reprenez les documents du projet avant de conclure sur le devis reçu : le périmètre signé et les conditions de correction comptent, ainsi que l'origine du problème. Un service extérieur qui change après la livraison peut demander une adaptation différente de la correction d'un défaut présent au départ.
Vérifiez notamment la période de correctifs incluse et les engagements de maintenance, s'il y en a. Le modèle de contrat informatique proposé par Numeum distingue la recette et une garantie contractuelle dont la durée et les conditions doivent être renseignées. C'est un exemple de contrat, pas une règle applicable automatiquement à votre projet.
Examinez le devis en suivant ces 4 étapes :
- 1
Décrivez le problème avec un exemple reproductible. Indiquez la version, les étapes suivies et le résultat obtenu. Pour un import, joignez un fichier d'essai sans données sensibles et précisez le résultat attendu.
- 2
Rapprochez le problème du besoin commandé. Retrouvez le ticket, ses critères et les échanges qui précisent le comportement convenu. Un refus de fichier vide et l'ajout d'un import d'entreprises ne correspondent pas au même travail.
- 3
Demandez ce que le devis ajoute ou remet en état. Le prestataire doit pouvoir expliquer la cause identifiée, l'intervention proposée et pourquoi il la considère comme extérieure à l'engagement initial.
- 4
Convenez du traitement et de sa validation. Distinguez les corrections et les évolutions dans le devis proposé. Précisez la prise en charge, le délai et le scénario à rejouer pour constater que le problème est résolu.
Auteur de l'article
Fabien Bousquet, CTO externalisé.
Pas une équipe, pas un sous-traitant. C'est moi qui vous écris, qui cadre, qui build, qui livre.
En savoir plus sur mon parcours →Questions fréquentes sur les devis et la correction des bugs
La correction d'un bug est-elle toujours gratuite ?
Le mot bug ne permet pas, à lui seul, de trancher la facturation. Il faut examiner le comportement commandé, la cause du problème et les engagements de correction. Dans un forfait bien cadré, les erreurs techniques prévisibles sont à traiter dans la réalisation de la fonctionnalité. Une adaptation à un changement extérieur ou un besoin supplémentaire demande un examen distinct.
Faut-il écrire tous les cas limites dans le devis ?
Vous devez préciser les règles métier et les conditions d'utilisation importantes. Le développeur apporte son expertise pour gérer les entrées invalides et les erreurs prévisibles. Un devis n'a pas à devenir un inventaire de toutes les fautes de saisie possibles. La réaction métier à une erreur peut toutefois demander un choix commun, comme refuser tout un fichier ou seulement ses lignes incorrectes.
Un devis au forfait peut-il changer en cours de projet ?
Vous pouvez faire évoluer le besoin, mais il faut rendre ce changement explicite avant de le développer. L'ajout peut faire l'objet d'un devis complémentaire ou d'un échange de périmètre convenu ensemble. Le backlog conserve alors la trace de ce qui entre dans le lot et de ce qui en sort. Une priorité plus basse ne retire pas, à elle seule, un ticket du forfait commandé.
Qui doit tester la livraison avant de la valider ?
Le développeur réalise ses contrôles techniques. Vous désignez côté client une personne qui connaît le métier pour essayer les fonctions livrées et vérifier les résultats attendus. Les tests automatisés aident à détecter les erreurs répétitives ; ils ne décident pas si une règle correspond à votre activité.
L'utilisation de l'IA change-t-elle la prise en charge des bugs ?
Le recours à l'IA ne suffit pas à justifier une nouvelle facture ni à promettre des corrections illimitées. La discussion porte sur le résultat commandé et les engagements du projet. L'IA peut aider à préparer les tests, mais le développeur doit vérifier ce qu'il livre. Le décryptage sur la création d'un outil interne avec l'IA détaille les choix à faire avant le développement.
Sources et documentation
L'analogie de la cuisine et la distinction entre erreurs techniques et nouveaux besoins viennent des explications de Fabien Bousquet. L'import et ses critères sont un exemple pédagogique fictif. Les 4 références ci-dessous documentent le cadrage et les tests. Le modèle Numeum et la référence DORA ont été consultés le 9 septembre 2026, les sources ISTQB et Cucumber le 8 septembre 2026.
Retrouvez tous les Décryptages et les décisions à prendre pour construire votre outil interne avec l'IA.