Une entreprise de pose de six personnes et quatre tableurs Excel. Un parcours type d'un après-midi : ce qu'il faut mettre dans le prompt, ce qui sort tout seul, ce qu'il faut ajuster à la main et ce qui change vraiment le premier mois.
Ce texte est un parcours d'un après-midi - de quatre tableurs Excel à un suivi de chantiers opérationnel. Il est écrit comme un cas type d'une petite entreprise de pose, mais le déroulé, l'ordre des étapes et les endroits où ça coince habituellement correspondent à ce que nous voyons le plus souvent lors de la création d'un premier espace de travail.
Point de départ : quatre tableurs et un panneau d'affichage
Six personnes. Deux poseurs sur le terrain, un commercial, une assistante, le patron et sa femme à la facturation. Chantiers : aménagement intérieur, en général 15 à 40 en cours simultanément.
Où tout cela vivait avant cet après-midi :
- chantiers_2026.xlsx - le tableur principal, que personne ne devait ouvrir en même temps qu'un autre
- contacts.xlsx - clients, parfois en double
- echeances.xlsx - ce qui est dû quand, mis à jour irrégulièrement
- heures.xlsx - relevés des poseurs, reconstitués en fin de mois
- un panneau au bureau avec les bons de commande papier
Le point de douleur décisif : deux fois en six mois, l'entreprise a oublié de facturer un chantier terminé. Une fois pour 2 700 €.
Ce qui est allé dans le prompt
Rien de technique. Littéralement ceci :
J'ai besoin d'un suivi de chantiers pour une entreprise de pose. Pour chaque chantier je veux savoir qui est le client, quelle est la date de pose, quel poseur y travaille, combien d'heures il a passées et si c'est facturé. Je veux voir ce qui est prévu cette semaine, et une alerte quand un chantier est terminé et n'a pas de facture.
Aucune « base de données relationnelle », aucun « moteur de workflow ». Une description de ce que le système doit faire, dans l'ordre où ça m'est venu.
Du prompt est sorti un plan, pas directement la chose finie
Le système a d'abord montré ce qu'il voulait créer - bases, liens et automatisations. Il n'a construit qu'après validation.
Ce qui en est sorti (et ce que j'ai dû ajuster)
En une vingtaine de minutes, trois bases reliées tenaient debout - Chantiers, Clients, Poseurs - plus les relevés d'heures rattachés au chantier. Avec ça, trois vues : calendrier des poses, tableau des chantiers non facturés et un kanban par statut.
Ce qui collait tout de suite :
- le lien entre chantier et client (un chantier, un client ; un client a plusieurs chantiers)
- le relevé d'heures rattaché au chantier et au poseur
- la vue « cette semaine » en calendrier
Ce que j'ai dû ajuster à la main :
- Les statuts de chantier. Ceux générés étaient génériques (Nouveau / En cours / Terminé). Nous en avons cinq, dont « En attente de matériel », notre cause de retard la plus fréquente. Renommer et ajouter a pris quelques minutes.
- Qui voit quoi. Les poseurs ne doivent pas voir les prix. Cela se règle à part - heureusement, car ce n'est pas à une machine d'en décider.
- Le texte du rappel. L'e-mail automatique avait un contenu générique. Je l'ai réécrit pour qu'il nous ressemble.
Au total : le prompt a fait 80 % de la structure, le reste était du réglage, pas de la construction.
La partie la plus difficile n'était pas technique
Ce qui m'a pris le plus de temps, c'est de décider ce qu'est un « chantier ». Si un chantier est une pose, ou toute la commande d'un client pouvant comporter trois poses. Aucun outil ne répondra à cette question pour vous - mais c'est une heure de réflexion, pas un mois de développement.
L'automatisation à l'origine de tout
Une règle, deux conditions :
Quand un chantier est au statut « Terminé » depuis plus de 3 jours et n'a pas de facture rattachée, envoie-moi un e-mail.
C'est toute la solution d'un problème qui a coûté 2 700 € à l'entreprise. Le réglage a pris six minutes.
Une deuxième règle est arrivée une semaine plus tard, quand il est apparu que les poseurs oubliaient de saisir leurs heures :
Chaque vendredi à 15 h, envoie à chaque poseur la liste des chantiers de la semaine sans relevé d'heures.
Ce qui a changé en un mois
Trois choses mesurables :
La facturation. Le premier mois, deux chantiers qui seraient passés à la trappe ont été facturés à temps. Cela seul a payé le système pour plusieurs années.
Fin des versions de tableur. La question « quel tableur est à jour » n'existe plus. Non parce que les gens se sont améliorés, mais parce qu'il n'y en a qu'un.
Le point du matin. Passé de vingt minutes à cinq, parce que personne n'a besoin de dire à voix haute où en est quoi. Le calendrier des poses montre la même chose plus vite.
Ce qui n'a pas changé : les poseurs oublient encore parfois leurs heures. Le système le rappelle simplement le vendredi. Un outil ne change pas les habitudes, il raccourcit seulement le délai avant qu'une erreur se voie.
Ce que je ferais autrement
Trois choses :
- Commencer plus petit. J'ai voulu ajouter tout de suite une gestion des matériaux. Inutile - au bout de deux semaines, plus personne ne l'utilisait. On peut ajouter n'importe quand.
- Impliquer les gens plus tôt. J'ai construit seul puis montré. Si j'avais demandé à l'assistante avant, j'aurais évité deux refontes des vues.
- Ne pas reprendre tout l'historique. J'ai importé trois ans de chantiers. La dernière année aurait suffi, le reste n'a fait qu'encombrer les vues.
Une démarche pas à pas pour la partie commerciale est dans Construire un CRM sans développeur. La marche à suivre pour le transfert de données dans Migrer depuis Excel ou Notion. Et sur le moment où quitter les tableurs, voyez Quand un tableur ne suffit plus. Tout le chemin, de la décision au premier mois en production, est mené par le guide du système d'entreprise sur mesure.
Questions fréquentes sur le démarrage d'un système propre
Une personne non technique y arrive-t-elle vraiment ?
Oui, si elle sait décrire comment son entreprise fonctionne. C'est la partie la plus difficile - et personne ne la fera à votre place. La réalisation technique est aujourd'hui secondaire.
Combien de temps prévoir ?
Pour une première version utilisable, un après-midi. Pour une version dont l'équipe est satisfaite, deux à trois semaines d'usage normal avec des ajustements au fil de l'eau.
Et s'il s'avère que j'ai mal conçu ?
Cela arrive presque toujours et c'est normal. Champs, statuts et liens se modifient en cours d'exploitation - contrairement à une application développée, où changer le modèle de données est un travail de développeur.