Personne ne porte le projet chez vous
Sans un interlocuteur interne qui connaît le terrain et qui peut arbitrer, un outil se construit sur des hypothèses. Il sera livré, il sera juste techniquement, et personne ne s’en servira.
Comment on travaille
Deux associés, du premier échange au run
Comprendre d’abord. Construire ensuite. Dire non quand il faut.
On commence par venir voir, sur place, deux à cinq jours. On mesure les frictions, on cadre un seul processus, et on livre quelque chose d’utilisable en quelques semaines. À chaque étape, un livrable nommé et une décision qui vous appartient — y compris celle d’arrêter.
Vous voyez ce que vous recevez à chaque étape, et vous pouvez reprendre la main à tout moment.
Les quatre temps
La même méthode à chaque projet.
Elle ne change pas selon la taille du client ni selon le montant. C’est ce qui la rend prévisible, et c’est ce qui vous permet de savoir où vous en êtes.
01
On vient voir
Sur place, 2 à 5 jours. On repart avec la liste de vos frictions, chiffrée en heures et en erreurs.
02
On cadre
Ce qu’on attaque, ce qu’on laisse, ce que ça doit rapporter. Vous validez avant qu’on écrive du code.
03
On construit
Un premier livrable utilisable en quelques semaines, puis des cycles courts. Vous voyez avancer.
04
On transmet
Documentation, formation, accès. Vous pouvez reprendre la main, ou nous confier le run.
La mesure du premier temps est la même que celle qu’on applique à la ressaisie : on chronomètre sur vos documents, avant de proposer quoi que ce soit.
Ce que vous recevez à chaque étape
Un livrable nommé, et une décision à prendre.
La colonne de droite est la plus importante : à aucun moment vous n’êtes engagé sans avoir vu ce que l’étape précédente a produit.
| Étape | Ce que vous recevez | La décision qui vous appartient |
|---|---|---|
| On vient voir | La liste de vos frictions, chiffrée en heures et en erreurs | Quels processus méritent qu’on s’en occupe — et lesquels ne les méritent pas |
| On cadre | Le périmètre, ce qu’on laisse de côté, et ce que ça doit rapporter | Vous validez avant qu’on écrive une ligne de code |
| On construit | Un premier livrable utilisable en quelques semaines, puis des cycles courts | À chaque cycle : on continue, on ajuste, ou on s’arrête |
| On transmet | La documentation, la formation et les accès | Reprendre la main vous-même, ou nous confier le run |
Vos droits
Écrits au contrat, pas laissés à la confiance.
C’est la partie qu’on ne trouve sur aucun site d’agence, et c’est celle qui décide un directeur informatique.
- La cession écrite des droits patrimoniaux sur ce que nous développons pour vous
- La propriété du dépôt : il vous est remis, avec l’historique
- Une clause de réversibilité, et la façon de la tester
- Un accord de sous-traitance au titre de l’article 28 du RGPD pour les données que nous traitons
- Un test de sortie : vous redéployez seul, devant nous
Le test de sortie
Le jour où vous le demandez, vous redéployez seul devant nous. Si vous n’y arrivez pas, ce n’est pas votre problème : c’est le nôtre.
La clause de réversibilité, concrètement
Le code que nous écrivons pour vous vous appartient. La cession des droits patrimoniaux est écrite au contrat, le dépôt vous est remis, et vous pouvez redéployer l’application vous-même, sur votre infrastructure ou chez un autre prestataire.
Ce n’est pas une intention, c’est une sortie testable : le jour où vous le demandez, vous redéployez seul devant nous. Si vous n’y arrivez pas, ce n’est pas votre problème, c’est le nôtre — la documentation et les accès font partie du livrable.
La même logique s’applique aux données : un accord de sous-traitance au titre de l’article 28 du RGPD encadre ce que nous traitons, et les modalités de restitution sont écrites avant de commencer, pas négociées à la sortie.
Dire non
Comment on décide de refuser un projet.
Trois critères. Si l’un des trois manque, nous vous le disons pendant le premier échange — et il n’y a pas de devis.
Le processus n’est pas montrable
Si personne ne peut nous montrer comment le travail se fait aujourd’hui — les documents réels, les exceptions, les contournements — nous ne mesurons rien. On écrit alors un logiciel pour un processus qui n’existe pas.
Le retour n’est pas démontrable
Si les heures récupérées ne couvrent pas le prix en un an, nous vous le disons avant de signer, et nous ne le faisons pas. Ce n’est pas de la modestie : c’est le seul critère qui protège les deux parties.
Qui travaille sur votre projet
Les deux associés, du premier échange au run. Aucun relais junior.
La personne qui comprend votre problème est celle qui le résout. Il n’y a pas d’avant-vente qui repasse le dossier à une équipe de production, parce qu’il n’y a pas d’équipe de production.
C’est une contrainte autant qu’une promesse : nous ne prenons pas plus de projets que nous ne pouvons en mener nous-mêmes. Cela veut dire dire non, y compris à des projets qui nous plairaient.
Ce qu’on ne fait pas
Quatre refus, et ils sont fermes.
Pas de site vitrine
Ce n’est pas ce qui fait gagner des heures à personne.
Pas de licence sans voir vos processus
Nous ne vendons pas un abonnement à un outil que vous n’avez pas encore essayé sur vos dossiers.
Pas d’IA quand une règle suffit
Si une règle simple résout le problème, nous écrivons la règle.
Pas de projet de neuf mois sans livrable intermédiaire
Vous devez pouvoir juger sur quelque chose d’utilisable, pas sur une promesse de fin de chantier.
Le troisième refus a sa page : pourquoi notre IA n’a pas le droit de calculer. Le quatrième explique notre façon de travailler par cycles courts.
Premier échange
Vous avez déjà jeté un logiciel ? Dites-le, on partira de là.
C’est une information utile, pas un aveu. Les projets qui échouent échouent presque toujours pour la même raison : l’outil a été choisi avant que le processus soit compris. Quarante-cinq minutes suffisent pour vérifier qu’on ne refera pas la même erreur.