La plupart des dirigeants de PME de services à qui je parle sont dans l'une de ces trois situations :
- Ils travaillent encore avec du papier (bons d'intervention, fiches, rapports). Ils savent que ce n'est plus tenable.
- Ils ont acheté un logiciel du marché. Il couvre 60 % du besoin, bloque les 40 % qui comptent, et coûte 1 000 à 3 000 € par mois.
- Ils ont déjà payé 20 à 40 k€ à un prestataire pour un projet sur-mesure qui traîne depuis 8 mois. Il n'est toujours pas en production.
Dans les trois cas, la conclusion est la même : « C'est forcément long et cher, on fera ça l'année prochaine. »
C'est faux. Un ERP terrain fonctionnel, sur-mesure, en production, livrable en 4 à 10 semaines selon le périmètre. Voici la méthode exacte.
Pourquoi 4 à 10 semaines, pas 6 mois
Ce n'est pas un miracle technique. C'est une conséquence de trois choix d'organisation :
- Un seul interlocuteur. Vous et moi. Pas de chef de projet qui fait le tampon, pas de sous-traitance, pas de comité de pilotage à trois niveaux.
- Une stack resserrée et maîtrisée. FastAPI, React, PostgreSQL, Docker. Pas de framework métier, pas de low-code, pas de dépendance externe qu'on ne maîtrise pas.
- Une discipline de scope. On liste ce qu'on fait, et surtout ce qu'on ne fait pas. La V1 couvre 80 % du besoin. Les 20 % restants arrivent en itérations 2, 3, 4.
Le reste, c'est une méthode en 5 étapes.
Étape 1 — Une journée terrain avec votre meilleur opérateur
Ça commence toujours pareil. Je passe une journée complète avec la personne qui fait le travail que je vais digitaliser : un technicien en tournée, un réparateur à l'atelier, un livreur sur sa route, un artisan sur ses chantiers.
Papier sur les genoux, j'observe. Je note :
- Chaque geste qu'il fait — y compris ceux qu'il ne remarque plus lui-même.
- Chaque information qu'il cherche — et où elle se trouve (carnet, téléphone, Excel, WhatsApp, mémoire).
- Chaque fois qu'il recopie une donnée d'un endroit à un autre.
- Chaque contrainte physique (gants, bruit, pluie, réseau absent).
À la fin de la journée, j'ai 10 à 15 pages de notes brutes qui valent plus qu'un cahier des charges de 40 pages rédigé en salle de réunion. Parce qu'elles décrivent le flux réel, pas le flux rêvé.
Cette étape est non-négociable. Sans elle, on finit par construire un logiciel que personne n'utilise parce qu'il ne colle pas à la vraie façon de travailler.
Étape 2 — Le brief en 2 pages
À partir des notes terrain, je rédige un brief ultra-condensé : WHY, HOW, STACK, CONTRAINTES, NON-GOALS. Deux pages A4. (Le format exact est détaillé ici.)
Ce document est la seule source de vérité du projet. On le relit ensemble, vous validez ou amendez, on le signe. Il cadre tout ce qui suit.
Exemple de structure pour un atelier de réparation vélo :
WHY : Remplacer les fiches papier + SMS clients par un système unifié. 5 réparateurs, ~40 vélos/jour, facturation mensuelle des abonnements flotte.
HOW :
- Entrée vélo : scan QR ou saisie, état initial photo, estimation temps/pièces
- Atelier : file d'attente priorisée, affectation réparateur, check-list par type de panne
- Sortie : signature client tactile, facture PDF auto, paiement Stripe ou compte pro
- Flotte : gestion contrats mensuels, relances automatiques
STACK : FastAPI · React · Postgres · Stripe · WeasyPrint
NON-GOALS : Pas d'e-commerce de pièces. Pas de CRM. Pas d'app client mobile.
Les non-goals sont la partie la plus importante. Ils empêchent le scope creep qui tue 90 % des projets.
Étape 3 — V1 fonctionnelle en 5 à 10 jours
Avec un brief clair, la V1 arrive vite. Très vite.
Jour 1-2 : modèle de données, migrations, auth.
Jour 3-5 : les 3 à 5 pages principales (tournée, intervention, clôture).
Jour 6-8 : PDF, signature, intégrations externes clés.
Jour 9-10 : déploiement Docker, DNS, SSL, compte admin.
À ce stade, l'application est déjà en ligne. Elle tourne sur mon infrastructure (ou la vôtre si vous préférez). Vous pouvez l'utiliser avec un vrai compte, créer une vraie intervention, générer un vrai PDF.
Ce n'est pas parfait. Ce n'est pas complet. Mais c'est testable. Et c'est là que tout bascule.
Étape 4 — Itérations avec vos opérateurs en vrai
On fait un premier test en condition réelle. Votre meilleur opérateur utilise la V1 sur 1 à 2 journées de travail.
À chaque fin de journée, on débriefe en 20 minutes. Il me dit :
- « Cette info, on la cherche 3 fois par jour, il faut la remonter en haut. »
- « Le bouton Envoyer est à côté du Supprimer, on va se planter. »
- « Il manque le champ X pour les clients de type Y. »
Chaque retour devient une itération. Je livre le lendemain. On retesté le surlendemain.
Ce cycle dure 2 à 6 semaines selon la complexité. À la fin, vous avez un outil qui a été raffiné par l'usage réel, pas par un chef de projet en réunion.
Étape 5 — Conformité, PDF, signature, facturation
Cette dernière phase est souvent sous-estimée, et c'est là que beaucoup de projets sur-mesure échouent. Elle couvre :
- Les PDF « officiels » (rapports, devis, factures) qui doivent être propres, archivables, conformes aux attentes de vos clients / marchés / bailleurs.
- La signature tactile avec hash SHA-256, horodatage et géolocalisation pour opposabilité juridique.
- La facturation : TVA multi-taux, numérotation séquentielle, prélèvements SEPA, Stripe, connecteur Pennylane ou Qonto.
- Les sauvegardes, le plan de reprise, la RGPD, les accès par rôle.
Ces chantiers prennent 1 à 2 semaines supplémentaires et font passer de « ça tourne » à « c'est solide pour 3 ans ».
Ce qu'on n'a PAS fait (et qu'on fera peut-être plus tard)
À la livraison V1 production, il y a toujours des choses qui ne sont pas dans l'outil :
- Pas de planning auto-optimisé (l'humain décide)
- Pas de module CRM complet (s'intègre à un CRM externe si besoin)
- Pas d'app client (portail web suffit dans 95 % des cas)
- Pas de multi-langue (sauf si vraiment nécessaire)
Ces fonctions sont rarement indispensables. Quand elles le deviennent, on les ajoute en itération ultérieure. Le sur-mesure a cet avantage : il grandit avec votre usage réel.
Les 3 risques à anticiper
1. L'indisponibilité de votre opérateur référent
Si votre meilleur technicien est malade ou en congé pendant la phase d'itération, le projet ralentit. On bloque les créneaux à l'avance.
2. Le scope creep déguisé
« Tant qu'on y est, est-ce qu'on pourrait aussi… ? » — ma réponse est presque toujours non. On note l'idée pour la V2. La V1 doit rester cadrée.
3. La dépendance au prestataire
Je livre toujours l'intégralité du code, de la documentation et des accès. Vous pouvez reprendre à la maintenance avec un autre développeur demain matin. Aucun enfermement propriétaire, aucune licence que je contrôle.
En résumé
La méthode tient en 5 temps :
- 1 jour — Shadowing terrain complet
- 2 jours — Brief 2 pages validé
- 5 à 10 jours — V1 en ligne, testable
- 2 à 6 semaines — Itérations en usage réel
- 1 à 2 semaines — Conformité, PDF, signature, facturation
Total : 4 à 10 semaines, un seul interlocuteur, un actif qui vous appartient.
La clé n'est ni la vitesse de frappe au clavier, ni un outil magique. C'est la compression de la boucle de décision. Pas de chef de projet, pas de comité, pas de prestataire qui attend le ticket suivant. Juste vous, votre terrain, et quelqu'un qui code pendant que vous vivez votre métier.