Ce que votre premier client rend obligatoire
Un devis arrive sur la table avec quatorze écrans et trois lots, et on vous demande lesquels partent dans le premier. La question est mal posée : le minimum d’un MVP — la première version mise entre les mains de vrais utilisateurs — ne se compte pas en fonctions.
Un premier lot tient quand il réunit deux choses : il produit la preuve que vous êtes venu chercher, et il couvre les responsabilités qu’un vrai client fait naître le jour où il dépend du service. Le reste peut sortir, rester tenu à la main, ou passer par un service existant. Sur notre grille publiée, relevée le 30 août 2026, un MVP de trois à cinq écrans est affiché 15 000 € hors taxes (HT) ; un produit de dix à quinze écrans, avec back-office riche, workflows métier complexes et intégrations tierces, 30 000 à 60 000 € HT. Entre les deux, elle n’affiche rien.
Ce guide vous fait écrire un contrat de test en sept lignes, puis calculer les heures humaines qu’il coûtera pendant qu’il tourne. Vous saurez alors quelles coupes sont gratuites, et laquelle fait sortir votre lot 1 de la seule bande que la grille tarifie.
Fil rouge du guide · exemple construit
Accordia : huit envies, un seul résultat vendu, six semaines pour le prouver
Exemple construit : la période, le nombre d’entreprises, les durées manuelles, l’abonnement et le coût du temps interne sont choisis pour l’exemple et ne viennent d’aucune source. Seuls les montants de prestation viennent de notre grille publiée, et ce n’est pas un dossier client. Accordia est un logiciel de suivi d’accords fournisseurs porté par une fondatrice et une opératrice. La liste de départ mélange huit envies : annuaire fournisseurs, demandes d’achat, dépôt de devis, circuit de décision, commentaires, signature électronique, paiement en ligne et tableaux de bord.
Le test réduit cette liste à un seul résultat vendu : un devis fournisseur reçoit une décision tracée, sans échange de fichier par courriel. Le pilote court du 7 septembre au 18 octobre 2026, soit six semaines, avec trois entreprises et un abonnement fixé à 240 € HT par mois et par entreprise dans cet exemple.
Vous ne pouvez pas nommer votre premier utilisateur ?
Alors aucun périmètre ne se décide. Un test se règle sur une personne précise, pas sur un marché : le diagnostic en six réponses tranche avant, quand le problème lui-même n’est pas encore nommé.
Prototype, pilote ou premier client : que pourrez-vous conclure ?
Le mot écrit sur le devis ne décide de rien. Le format du test, lui, fixe la conclusion que vous aurez le droit de tirer et les responsabilités que vous devrez assumer. Le manuel de service britannique sépare de la même façon l’alpha, où l’on teste les hypothèses risquées sur des prototypes, la bêta privée, où de vrais utilisateurs entrent avec un support rapproché, et la phase live, qui suppose des responsables, une disponibilité et une mesure. C’est un cadre de service public, pas une norme pour un logiciel privé ; la découpe, elle, se transpose.
| Format | Qui utilise, avec quelles données | Ce que vous pourrez conclure | Ce qui devient non négociable |
|---|---|---|---|
| Prototype sans production | Personne d’extérieur, données fictives | L’incertitude que vous avez choisie, rien de plus | Aucune donnée réelle n’entre, y compris « juste pour tester » |
| Pilote accompagné | 2 à 5 clients réels (estimation éditoriale Hagnéré Code, aucune source ne borne un pilote), limites annoncées, équipe présente | Que le résultat s’obtient dans des conditions accompagnées | Accès nominatifs, reprise des données, canal d’aide nommé |
| Premier client en production | 1 client dépend du service pour son travail quotidien | Que le produit tient sans vous derrière l’écran | Les 7 responsabilités de la section 04, quel que soit le mot du devis |
Le piège tient à un enchaînement court : le devis dit « MVP », le client signe, ses données réelles entrent, et vous êtes en production sans l’avoir décidé. Le règlement européen ne lit pas le mot du devis : dès qu’une donnée personnelle réelle est traitée, ses articles 5, 25 et 32 s’appliquent — minimisation, protection dès la conception, sécurité proportionnée au risque.
Le test des dix minutes
Écrivez la ligne d’arrivée en une phrase, avant tout le reste
Remplacez les crochets : « Pendant [période exacte], avec au plus [nombre] clients, nous délivrons [résultat] par [parcours] ; [événement observable] fera preuve. » Sur le cas construit : du 7 septembre au 18 octobre 2026, avec au plus trois entreprises, un devis fournisseur reçoit une décision tracée ; la décision enregistrée puis exportée fera preuve. Un crochet que vous ne savez pas remplir désigne une décision encore ouverte : tranchez-la avant le devis.
Une journée du client montre ce que la liste d’écrans oublie
La méthode tient en une heure et une feuille. Prenez un utilisateur nommé, une journée, et déroulez du moment où il veut le résultat jusqu’à celui où il l’a. À chaque étape, écrivez ce qui se passe quand ça rate. Le devis décrit le parcours quand tout marche ; les fonctions manquantes apparaissent dans ce qui rate.
- Entrée. Qui l’invite, et que voit-il si son accès est refusé ? Une page blanche est un incident de support.
- Première donnée. D’où vient-elle, et que se passe-t-il si elle est fausse ? Un import raté sans message lisible fait revenir l’utilisateur vers vous.
- Action de valeur. Quel geste produit le résultat vendu, et où cet événement est-il enregistré ?
- Échec. Qui détecte, qui répond, qui restaure, et en combien de temps ?
- Aide. Où écrit-il, et quel délai lui a-t-on réellement annoncé ?
- Sortie. Comment récupère-t-il ses données si le test s’arrête ? Cette ligne n’a pas d’écran, et la section 07 en donne le prix.
Reste la mesure, et elle décide de ce que le test aura prouvé. Une connexion n’est pas un résultat, un clic non plus. L’événement de preuve d’Accordia porte l’identifiant du devis, le rôle de la personne et l’horodatage ; le seuil est écrit avant le début : au moins deux des trois entreprises obtiennent une décision tracée sans courriel avant le 18 octobre.
Et si une seule y arrive ? On ne prolonge pas de deux semaines pour aller chercher la deuxième. On rouvre les entretiens pour comprendre pourquoi la deuxième entreprise a continué d’envoyer des pièces jointes, et on accepte que la réponse puisse être « le problème n’était pas là ». Déplacer le seuil après coup revient à changer l’hypothèse pour qu’elle devienne vraie.
Sept responsabilités, et le propriétaire de chacune
Sept familles suffisent à couvrir ce qu’un test met en jeu. Elles ne décrivent aucun module logiciel : ce sont des responsabilités, et chacune doit trouver une personne, pas un écran. Pour chaque ligne, écrivez la décision, le responsable, la preuve attendue, la reprise en cas d’échec et l’événement qui la fera revoir.
| Famille | La question à trancher | Le test d’acceptation à réussir |
|---|---|---|
| Parcours de valeur | Quel résultat le client vient-il chercher, et par quel chemin ? | Une personne obtient le résultat vendu, et l’événement est enregistré. |
| Comptes et accès | Qui invite, qui entre, qui sort ? | Un compte retiré ne voit plus rien, vérifié avec un vrai compte. |
| Données et continuité | Que se passe-t-il si la base disparaît demain matin ? | Une restauration a été rejouée, chronométrée, et l’export du client s’ouvre. |
| Vente et droits associés | Qu’est-ce qui ouvre les droits, et qu’est-ce qui les referme ? | Un paiement refusé referme les droits sans intervention de nuit. |
| Aide et incidents | Où un utilisateur bloqué écrit-il, et qui lui répond ? | Une demande envoyée le matin trouve son destinataire le jour même. |
| Administration et exploitation | Qui corrige une donnée fausse, et avec quelle trace ? | Une correction est faite sans accès improvisé, et le journal la garde. |
| Mesure et sortie | Sur quel événement décidez-vous de continuer ou d’arrêter ? | L’événement distingue un résultat obtenu d’une simple connexion. |
Trois de ces lignes s’appuient sur un référentiel extérieur qui recommande, là où le règlement européen cité à la section 02 oblige. Pour les données, les fondamentaux de la sauvegarde publiés par l’ANSSI en version 1.1 du 27 novembre 2025 recommandent des tests réguliers et une procédure de restauration : une copie jamais restaurée ne prouve rien. Pour la sécurité, le catalogue OWASP ASVS, version stable 5.0.0 publiée le 30 mai 2025, permet de choisir un sous-ensemble proportionné. Pour l’accessibilité, les critères WCAG 2.2, recommandation du 12 décembre 2024, se testent écran par écran et ne s’ajoutent pas après coup sans refaire les gabarits.
Cinq réponses possibles, aucune par défaut
Ce qu’on écrit en face d’une responsabilité
- Construire dans le produit. Le comportement porte la preuve recherchée. Écrivez le test d’acceptation et la reprise en cas d’échec.
- Opérer manuellement. Une personne délivre le résultat dans les limites du test. Écrivez son nom, le calcul de charge, la limite et le moment où ce choix sera revu.
- Intégrer un service existant. Écrivez les états, les erreurs, le repli, la sortie et le responsable — l’intégration déplace le travail, elle ne supprime pas la responsabilité.
- Reporter avec déclencheur. Réservé au prototype et au pilote borné, avec le motif et l’événement qui rouvrira le sujet.
- À vérifier. La décision n’est pas encore défendable. Écrivez la question, le responsable et la preuve à obtenir ; jamais zéro.
Une famille déclarée non nécessaire doit l’être à cause du format, pas par fatigue. Devant un premier client en production, la responsabilité reste active : tenue à la main ou confiée à un service, jamais remise à plus tard. Le calculateur de la section 08 l’applique.
Achat autonome : ce sont les échecs qui coûtent, pas la page de paiement
Si le client paie seul par carte, la famille « Vente et droits associés » devient nécessaire. La documentation Stripe sur les webhooks d’abonnement liste les événements à traiter, à commencer par l’échec de paiement d’une facture et les changements d’état qui ouvrent ou referment un accès. Écrivez ce qui se passe pour un paiement refusé, retardé, contesté ou annulé. Sans cette procédure, la page encaisse les cas nominaux et laisse les autres ouverts : le client garde son accès, et vous gardez une facture impayée.
Qu’est-ce qu’on ajoute à tort dans le premier lot ?
Un premier lot ne gonfle pas d’un coup : il gonfle par ajouts qui paraissent raisonnables un par un. En voici six. La colonne « ce que ça pèse » est exprimée en écrans et non en euros : c’est une estimation éditoriale Hagnéré Code, à confronter à votre devis, pas un tarif.
| Ce qu’on ajoute | Ce que ça pèse | Ce qui suffit pendant le test |
|---|---|---|
| Un écran d’administration complet | 2 à 3 écrans, pour une ou deux personnes | Un accès en lecture seule à la base, une personne nommée, trois requêtes écrites d’avance |
| Une matrice de rôles et de permissions | 1 écran, plus de la complexité dans toutes les pages | Deux rôles écrits, et la liste des données qu’un rôle ne doit jamais voir |
| L’authentification unique d’entreprise | Une intégration par annuaire client, jamais mutualisable | Des invitations nominatives ; l’authentification unique se chiffre quand le contrat est signé |
| Une application mobile | Un second produit à construire, à publier et à maintenir | Un site qui reste lisible sur un écran de téléphone |
| Un tableau de bord de statistiques | 1 à 2 écrans qui ne changent aucune décision du test | Un événement nommé, un export, et la personne qui les lit |
| Le paiement en ligne | Les états d’échec, bien plus que la page de paiement | Un contrat et une facture, tant que les clients tiennent dans la capacité |
Le substitut de la première ligne couvre la consultation et la correction, pas la restitution : produire un fichier qu’un client reprend dans son outil relève de « Données et continuité », et la section 07 en donne le prix.
Additionnez la deuxième colonne. Trois lignes s’expriment en écrans : 2 à 3 pour l’administration, 1 pour les rôles, 1 à 2 pour le tableau de bord, soit 4 au minimum et 6 au maximum. Les trois autres ne se comptent pas ainsi : l’authentification unique ajoute une intégration par annuaire client, l’application mobile un second produit, le paiement en ligne une série d’états d’échec. Un MVP de trois à cinq écrans qui les absorbe tous en compte sept à onze.
Le rapport prix sur écran donne l’ordre de grandeur : 15 000 € HT pour trois à cinq écrans, soit 3 000 à 5 000 € HT par écran ; 30 000 à 60 000 € HT pour dix à quinze écrans, soit 2 000 à 6 000 € HT par écran. La division part de 15 000 € : la grille réserve son ticket d’entrée de 6 900 € HT au site vitrine. Ce n’est pas un prix unitaire : le premier écran porte l’authentification, la base, le déploiement et la mise en ligne, le douzième ne les porte plus.
La grille dit surtout ceci : entre six et neuf écrans, elle n’affiche aucun montant. Les deux forfaits publiés sont séparés de 15 000 € HT, 15 000 contre 30 000 € HT à la borne basse, mais ils ne couvrent pas le même produit : le second ajoute back-office riche, workflows métier complexes, intégrations tierces et fonctions d’intelligence artificielle. Cet écart mesure une marche entre deux périmètres différents, pas le prix de cinq écrans. Un lot 1 sorti de la bande trois à cinq écrans se chiffre au devis.
Deux de ces six lignes méritent parfois d’entrer dès le premier lot, et le taire serait malhonnête. Le paiement en ligne devient obligatoire dès que le client achète seul : les états d’échec ne se rattrapent pas à la main. Les rôles le deviennent quand le produit affiche des salaires, des marges ou des données de santé, car la sécurité proportionnée au risque exigée par l’article 32 du règlement européen ne se reporte pas au lot 2.
Combien de temps humain votre MVP coûte-t-il chaque semaine ?
Tenir une opération à la main est souvent le bon choix, jamais le choix gratuit : le travail existe, il est payé en heures et non en lignes de code. Le calcul commence par la période, et une seule : les occurrences par client et la capacité disponible portent sur cette même période, sans conversion implicite.
sur une même période nommée : charge d’une opération = minutes par occurrence × occurrences par client sur toute la période × clients charge manuelle totale = somme des opérations manuelles capacité restante = capacité totale disponible sur cette même période − charge manuelle totale
| Famille | L’opération et son calcul | Total |
|---|---|---|
| Comptes et accès | Créer ou reprendre les accès du pilote — 12 min × 2 fois par client × 3 clients | 72 min |
| Données et continuité | Préparer et contrôler l’import initial — 20 min × 1 fois par client × 3 clients | 60 min |
| Vente et droits associés | Contrôler le contrat et émettre la facture pilote — 15 min × 1 fois par client × 3 clients | 45 min |
| Aide et incidents | Tenir une permanence d’aide planifiée — 10 min × 2 fois par client × 3 clients | 60 min |
Sur les six semaines du pilote, Accordia consomme 237 minutes pour une capacité déclarée de 300 minutes : il reste 63 minutes. Ramené à la semaine, cela fait 39,5 minutes pour 50 minutes disponibles : moins d’une heure par semaine, tant que le pilote reste à trois clients. Traduites avec l’hypothèse posée plus bas, ces 237 minutes valent 3 heures et 57 minutes, soit environ 198 € ; la capacité complète de 300 minutes vaut 250 €. Refaites le calcul avec vos nombres : la charge croît comme le nombre de clients, la capacité non.
À cinq clients, les mêmes opérations demandent 395 minutes et dépassent la capacité de 95 minutes. À six clients, le double du départ, elles atteignent 474 minutes et dépassent de 174 minutes. Sur ces durées et cette capacité, le dépassement commence dès le quatrième client : chaque client coûte 79 minutes, et 79 × 4 = 316 minutes pour 300 disponibles.
Ce décompte est planifié, pas subi
Les limites écrites sur chaque opération le disent : deux interventions d’accès par client, un import initial, une facture, deux permanences d’aide. Un incident imprévu n’entre pas dans cette somme, puisque ces limites ne couvrent que le planifié. Tenez donc deux lignes séparées, l’une pour la permanence prévue, l’autre pour la provision d’incident : réunies, la première absorbe la seconde sans qu’on le voie.
Aucun nombre de cette section ne sort d’une source : les minutes, les occurrences et la capacité appartiennent au cas construit, et le coût du temps interne est posé de la même façon — 350 € le jour chargé, soit 50 € l’heure sur sept heures. Cette dernière hypothèse est écrite ici pour que vous puissiez la contester ; votre expert-comptable ou votre contrôleur de gestion sort la vôtre à partir du salaire brut, des charges patronales et des jours réellement travaillés. Le calcul dit que la charge décrite tient dans la capacité saisie, sous les hypothèses écrites. Il ne dit rien de la sécurité ni de la légalité du test.
Ce qui rate quand on coupe la mauvaise chose
Les trois incidents ci-dessous sont construits sur le cas Accordia, les deux premiers pendant le pilote, le troisième après. Les durées, les volumes, l’abonnement et le coût du temps interne sont choisis pour l’exemple et ne viennent d’aucune source ; ce ne sont pas des dossiers clients. Chacun correspond à une coupe qui paraissait sans conséquence au moment de signer.
L’export reporté : 700 € et 840 minutes hors budget
La famille « Données et continuité » est marquée « reporter » pour tenir le budget du lot 1. Au vingt-quatrième jour, le 30 septembre, la deuxième entreprise demande à récupérer ses décisions pour son propre outil. L’accès en lecture seule de la section 05 rend bien les lignes, mais les trois requêtes écrites d’avance servaient à consulter et à corriger : aucune ne reconstitue une décision complète, motif et pièces compris. L’opératrice reprend les 312 décisions une par une pendant deux jours, soit 2 × 350 = 700 € au taux posé plus haut, et la restitution finale, prévue le 18 octobre, arrive deux jours plus tard. Ces deux jours pèsent 840 minutes, soit 2 × 7 heures, quand la capacité manuelle du pilote entier valait 300 minutes : l’incident coûte 2,8 fois le budget humain de six semaines. Le calculateur avait tranché avant le départ : la variante « continuité reportée » laisse 177 minutes parfaitement calculées, et maintient quand même l’arrêt.
La durée inconnue prise pour zéro : 25 % de capacité en trop
La durée de l’opération d’accès reste « à vérifier ». L’équipe démarre quand même, en la comptant pour zéro — un zéro qui n’ajoute aucune ligne et ne se voit donc nulle part. Mesurée sur le premier client, l’opération vaut 35 minutes, parce que chaque service informatique client exige une inscription sur liste blanche : 35 × 2 × 3 = 210 minutes. Avec les 165 minutes des trois autres opérations, le pilote demande 375 minutes pour 300 disponibles, soit 75 minutes de trop et un quart de la capacité envolé. Le calculateur avait refusé de conclure et affiché « partiel/inexploitable » sur ces mêmes 165 minutes.
Le paiement autonome sans procédure d’échec : 2 880 € HT non encaissés
Cette fois le pilote a conclu : Accordia vend son produit au-delà du 18 octobre, et ouvre l’achat par carte au troisième mois d’exploitation sans écrire ce qui se passe quand un paiement échoue. Trois cartes expirent, l’événement d’échec de facture part bien, personne ne l’écoute, et les accès restent ouverts. À 240 € HT par mois et par entreprise, trois abonnements ouverts quatre mois sans paiement font 2 880 € HT facturés et jamais encaissés. La règle manquante tenait en une ligne : quel événement referme l’accès, et au bout de combien de jours. Écrite après coup, elle se corrige sur un produit qui a déjà des utilisateurs : rattraper quatre mois d’événements, décider quels accès se referment, rouvrir la conversation avec trois clients de bonne foi.
L’ordre compte
Le premier blocage applicable fixe le verdict
- Une décision indispensable est inconnue — la période du test, ou la nécessité de la vente en achat autonome.
- Une responsabilité nécessaire au test est reportée, ou une famille est reportée devant un premier client en production.
- Une opération manuelle n’est pas bornée.
- La capacité manuelle est dépassée.
- Le format ne permet pas la production, ou le contrat attend sa relecture.
Remplir le contrat sur votre propre dossier
Le formulaire s’ouvre vide, et vous pouvez charger l’exemple construit d’un clic pour voir à quoi ressemble un contrat rempli. Tout se calcule dans votre navigateur : aucune requête réseau, aucun stockage, aucun téléchargement. Le résultat réunit la période, les sept décisions, les équations manuelles, les inconnues restées ouvertes et un texte que vous copiez tel quel pour l’envoyer à votre développeur. Les entrées sont bornées à un million pour les clients, les minutes et les occurrences ; le nombre de clients se saisit en entier, les minutes, les occurrences et la capacité acceptent trois décimales au plus — ce sont des limites techniques, pas des repères commerciaux.
Outil local, sans envoi
Écrire le contrat de votre premier test réel
Rien n’est prérempli. Vos saisies restent dans cette page : aucun envoi, cookie ou stockage local. L’outil calcule uniquement le travail manuel planifié. Un incident imprévisible reste à traiter : il ne vaut jamais zéro. Les occurrences par client et la capacité totale doivent couvrir toute la même période nommée, sans conversion implicite. L’outil n’attribue aucun score.
Règles de saisie : clients entiers de 1 à 1 000 000 ; minutes par occurrence et occurrences par client strictement supérieures à 0 et au plus égales à 1 000 000 ; capacité totale de 0 à 1 000 000 minutes. Les décimaux acceptent trois décimales au maximum et un point comme séparateur. Une valeur vide, négative, nulle pour une opération, trop précise ou hors limite reste à corriger.
Nommez la période exacte couverte par le test. Toutes les occurrences par client et la capacité manuelle totale saisie portent sur l’ensemble de cette même période. Le moteur ne convertit ni semaine, ni jour, ni disponibilité d’une personne.
Les inconnues restent reliées à leur champ et listées dans le résultat. Affichez les détails sous chaque saisie lorsque vous voulez les corriger une par une.
Décidez pour chacune des sept familles
« Nécessaire » dépend de votre test, de vos données, du contrat et du premier client. Reporter une famille nécessaire provoque un STOP. Pour un premier client en production, « Non » puis « Reporter » ne peut contourner aucune des sept responsabilités. Cela n’impose pas sept fonctions : un choix manuel ou intégré reste possible.
Résultat calculé — décision humaine séparée
STOP_REQUIRED_DECISIONS_UNKNOWN — STOP — décisions indispensables à vérifier
Au moins une décision structurante, une preuve, la période du test ou une entrée numérique manque ou est invalide. Aucune inconnue n’est convertie en zéro.
Prochaine action : Complétez d’abord les décisions listées, puis relisez les capacités une par une.
Période commune du calculÀ vérifierLes occurrences par client et la capacité totale portent sur toute cette même période, sans conversion implicite.
Charge planifiée sur la période
À vérifierpartiel/inexploitable
Capacité totale sur la même période
À vérifier
Reste après charge
partiel/inexploitable
Décisions à vérifier
- Format du test à vérifier
- Période couverte par le test à vérifier
- Résultat métier vendu à vérifier
- Événement qui prouve le résultat à vérifier
- Mode de vente à vérifier
- Nombre de clients du test à vérifier
- Capacité manuelle disponible à vérifier
- Parcours de valeur : nécessité pour le test à vérifier
- Parcours de valeur : traitement à vérifier
- Parcours de valeur : preuve attendue à vérifier
- Comptes et accès : nécessité pour le test à vérifier
- Comptes et accès : traitement à vérifier
- Comptes et accès : preuve attendue à vérifier
- Données et continuité : nécessité pour le test à vérifier
- Données et continuité : traitement à vérifier
- Données et continuité : preuve attendue à vérifier
- Vente et droits associés : nécessité pour le test à vérifier
- Vente et droits associés : traitement à vérifier
- Vente et droits associés : preuve attendue à vérifier
- Aide et incidents : nécessité pour le test à vérifier
- Aide et incidents : traitement à vérifier
- Aide et incidents : preuve attendue à vérifier
- Administration et exploitation : nécessité pour le test à vérifier
- Administration et exploitation : traitement à vérifier
- Administration et exploitation : preuve attendue à vérifier
- Mesure et sortie : nécessité pour le test à vérifier
- Mesure et sortie : traitement à vérifier
- Mesure et sortie : preuve attendue à vérifier
# Contrat du premier client SaaS — brouillon local - Statut : STOP_REQUIRED_DECISIONS_UNKNOWN - Lecture : STOP — décisions indispensables à vérifier - Format du test : À vérifier - Période couverte par le test : À vérifier - Résultat vendu : À vérifier - Événement de preuve : À vérifier - Mode de vente : À vérifier - États d’achat autonome et de droits : Non applicable — achat autonome non retenu - Procédure d’échec de paiement autonome : Non applicable — achat autonome non retenu - Clients du test : À vérifier - Capacité manuelle totale déclarée sur cette période : À vérifier ## Capacités | Famille | Nécessaire | Traitement | Responsable | Preuve | Reprise sur échec | Déclencheur | | --- | --- | --- | --- | --- | --- | --- | | Parcours de valeur | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier | | Comptes et accès | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier | | Données et continuité | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier | | Vente et droits associés | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier | | Aide et incidents | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier | | Administration et exploitation | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier | | Mesure et sortie | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier | ## Charge manuelle planifiée Période commune : À vérifier Les occurrences par client et la capacité totale couvrent l’ensemble de cette même période, sans conversion implicite. Aucune équation exploitable. À vérifier. Les incidents imprévisibles ne valent jamais zéro : ils restent hors de la somme planifiée et exigent la reprise sur échec écrite dans chaque famille. ## Décisions à vérifier - Format du test à vérifier - Période couverte par le test à vérifier - Résultat métier vendu à vérifier - Événement qui prouve le résultat à vérifier - Mode de vente à vérifier - Nombre de clients du test à vérifier - Capacité manuelle disponible à vérifier - Parcours de valeur : nécessité pour le test à vérifier - Parcours de valeur : traitement à vérifier - Parcours de valeur : preuve attendue à vérifier - Comptes et accès : nécessité pour le test à vérifier - Comptes et accès : traitement à vérifier - Comptes et accès : preuve attendue à vérifier - Données et continuité : nécessité pour le test à vérifier - Données et continuité : traitement à vérifier - Données et continuité : preuve attendue à vérifier - Vente et droits associés : nécessité pour le test à vérifier - Vente et droits associés : traitement à vérifier - Vente et droits associés : preuve attendue à vérifier - Aide et incidents : nécessité pour le test à vérifier - Aide et incidents : traitement à vérifier - Aide et incidents : preuve attendue à vérifier - Administration et exploitation : nécessité pour le test à vérifier - Administration et exploitation : traitement à vérifier - Administration et exploitation : preuve attendue à vérifier - Mesure et sortie : nécessité pour le test à vérifier - Mesure et sortie : traitement à vérifier - Mesure et sortie : preuve attendue à vérifier ## Décision humaine Au moins une décision structurante, une preuve, la période du test ou une entrée numérique manque ou est invalide. Aucune inconnue n’est convertie en zéro. Complétez d’abord les décisions listées, puis relisez les capacités une par une. Ce brouillon n’est ni une autorisation juridique, ni une homologation de sécurité, ni une mise en production.
Faut-il vraiment écrire du code pour apprendre ça ?
Chaque incertitude a son test le moins cher. Voici quatre chemins, du plus économe au plus engageant : le développement est le dernier de la liste, pas le premier.
- Le problème est-il prioritaire ? Des entretiens et un pré-engagement écrit répondent en quelques jours. Ce qu’ils doivent prouver : une situation précise conduit à une décision réelle, pas à un accord poli.
- Le parcours est-il compris ? Une maquette cliquable avec des données fictives suffit. Ce qu’elle doit prouver : l’utilisateur accomplit le parcours et sait réexpliquer ce qu’il vient de faire.
- Le résultat crée-t-il de la valeur ? Une opération tenue à la main, de bout en bout, pour les trois premiers clients. Ce qu’elle doit prouver : le résultat vaut ce qu’on demande de le payer.
- La capacité existe-t-elle déjà ailleurs ? Un outil du marché ou une plateforme interne peuvent couvrir le besoin. Le guide Power Apps ou application sur mesure chiffre exactement ce type d’arbitrage sur cinq ans.
Chacun de ces chemins permet de conclure « construisez moins maintenant, et gardez le budget pour le lot 2, quand vous saurez quoi y mettre ». Notre propre point d’entrée payant existe pour cela : le Discovery Sprint, 1 500 € HT sur deux jours ; si la phase suivante est lancée avec nous, le devis précise la déduction applicable. Au-delà de 8 000 € HT de projet, ce cadrage payé est systématique chez nous, parce qu’un périmètre décidé sans preuve se repaie deux fois.
Qui tranche, et sur quelle preuve ?
Avant la première invitation réelle, une personne désignée relit le contrat en entier : la promesse, les preuves attendues, le nom en face de chaque responsabilité, la restauration rejouée, les droits d’accès, le canal d’aide et les termes convenus avec le client. Le verdict du calculateur ne remplace pas cette relecture : « candidat » signifie seulement que le contrat est assez renseigné pour entrer en revue.
Quatre décisions sortent de cette relecture, et trois réduisent le périmètre. Continuer, quand la preuve reste utile et que les responsabilités sont acceptées. Réduire le format, quand un prototype répond à la même question sans exposer un client. Changer un traitement, quand la charge ou le risque rendent le choix actuel intenable. Arrêter ou différer, quand le test n’apprend plus rien de décisif — avec le motif écrit, faute de quoi rien n’empêche la même demande de revenir telle quelle.
Un chiffre doit figurer dans cette décision, et il n’apparaît sur aucune ligne d’un devis de développement : l’exploitation. Notre grille publie un repère indicatif d’environ 2 500 € HT par mois pour le scénario de maintenance le plus léger. Douze mois à ce repère font environ 30 000 € HT, soit la borne basse du forfait de développement suivant, qui va de 30 000 à 60 000 € HT. La première année d’exploitation pèse donc au moins autant que l’entrée de ce forfait, autant le savoir avant de dire oui. Le repère n’est pas un devis : le forfait réel est fixé au contrat.
Les critères qui feront accepter la livraison se rédigent avec le plan de recette d’une application métier, les contrôles à passer avant d’ouvrir le service sont listés dans les contrôles de sécurité d’une application métier, et une demande comparable entre plusieurs équipes se prépare avec le cahier des charges SaaS. Si vous voulez une lecture extérieure de votre lot 1, vous pouvez décrire votre projet à Hagnéré Code, en précisant que renoncer reste une issue acceptable.
Ne rien construire peut être la bonne décision
Si l’opération tenue à la main rend déjà le service attendu et que la charge tient dans votre capacité, un logiciel n’apportera qu’un coût de développement et un coût d’exploitation. Le calcul de la section 06 sert autant à justifier un projet qu’à le repousser d’un an.
Transparence. Hagnéré Code développe des applications SaaS sur mesure et perçoit des honoraires si vous retenez cette option — l’une de celles que ce guide arbitre. Rien ici n’exige de passer par nous : les sept familles, le calcul de charge et le décompte des écrans se refont avec vos nombres, et le calculateur ne transmet rien. Les montants de notre grille ont été relevés le 30 août 2026 et sont à revérifier tous les douze mois. Aucun prix, aucun délai et aucun résultat ne sont garantis par cette page : seul un devis signé engage.