Quand un dirigeant de TPE ou de PME me parle de no-code, il pense site, application client, parfois marketplace. Presque jamais à l'outil que son équipe ouvre tous les matins : ce mélange de tableurs partagés, de fils de discussion et de copier-coller qui fait tourner la boîte sans que personne ne l'ait vraiment conçu. C'est pourtant là que le no-code assisté par IA change le plus de choses, et le plus vite. Je le mets désormais en premier chantier, avant tout ce qui se voit de l'extérieur.
De quoi on parle exactement
Un outil métier n'est pas un ERP. C'est l'endroit unique où vit l'information dont ton équipe a besoin pour avancer sur un processus : le suivi des dossiers, le planning des interventions, l'état des devis, le parcours d'un candidat. Un processus, pas toute l'entreprise.
Aujourd'hui, ce rôle est tenu par un assemblage : un tableur partagé, une boîte mail, un canal de discussion, et la mémoire de deux ou trois personnes. Ça tient très bien jusqu'à un certain volume. Puis ça se met à coûter cher d'une manière difficile à voir dans les comptes : la même information saisie deux fois, les versions qui divergent, les demi-heures passées à reconstituer où en est un dossier.
Pourquoi il passe avant le site
Quatre raisons, et aucune n'est une question de goût.
Le besoin existe déjà. Un site parle à des gens que tu n'as pas encore ; il faut deviner ce qu'ils veulent. Un outil métier sert un travail que tu fais tous les jours. Tes équipes te décrivent le besoin en une heure, sans étude.
Les utilisateurs sont dans la pièce d'à côté. Tu montres une V1 le mardi, tu sais le jeudi ce qui cloche. Ce cycle de correction est ce qui fait la qualité d'un outil, et il est presque gratuit en interne.
Le périmètre se ferme. Un processus a un début, une fin et un responsable. C'est exactement ce qu'il faut pour construire vite sans dériver.
C'est le socle de tout le reste. Brancher un agent IA sur un tableur bricolé ne donne pas un agent utile, ça donne un bricolage plus rapide. L'automatisation suppose une donnée structurée quelque part. L'outil métier, c'est ce quelque part.
Choisir le premier processus
Le réflexe naturel consiste à prendre le sujet le plus douloureux. C'est rarement le bon. Le plus douloureux est souvent le plus politique, le plus transverse, celui où trois services ne sont d'accord sur rien.
Prends plutôt le processus qui coche ces trois cases : un volume régulier, un propriétaire identifié, une règle du jeu déjà stable. Les signaux qui ne trompent pas :
- une information recopiée d'un outil à l'autre chaque semaine ;
- un fichier que tout le monde utilise et que plus personne n'ose modifier ;
- la question « on en est où sur ce dossier ? » à laquelle personne ne répond sans ouvrir trois onglets ;
- une relance faite à la main tous les vendredis, toujours par la même personne.
Si tu trouves les quatre au même endroit, tu as ton premier chantier.
Ce qui rate
J'ai vu les mêmes erreurs assez souvent pour les poser noir sur blanc.
Vouloir tout couvrir en V1. L'outil devient un ERP maison en trois mois, personne ne l'a utilisé entre-temps, et il arrive trop tard pour être corrigé. Une V1 qui couvre un tiers du besoin et tourne pour de vrai vaut mieux qu'une V2 complète jamais mise en service.
Construire sans le propriétaire du processus. Sans lui, l'outil sort, et l'ancienne feuille de calcul ressort la semaine suivante. C'est le mode d'échec le plus fréquent, et il n'a rien de technique.
Oublier la reprise de l'existant. Les données d'aujourd'hui doivent entrer dans l'outil au démarrage. Un outil vide face à un tableur plein, le tableur gagne toujours.
Ne pas décider qui maintient. Si personne dans l'équipe ne peut ajouter un champ ou corriger un statut sans passer par toi ou par un prestataire, tu n'as pas livré un outil, tu as créé une dépendance. C'est le point que je fais écrire dans le périmètre, pas celui qu'on découvre six mois après.
Ce qui marche
Une V1 sur un seul processus, mise en service avant d'ajouter quoi que ce soit. J'écris d'abord les cinq actions que l'outil doit permettre — créer, avancer, retrouver, relancer, sortir la liste — et tout le reste attend explicitement une V2.
Ensuite, un dossier réel suivi de bout en bout dans l'outil, devant la personne qui fait le travail. C'est le seul test qui compte : ce qu'elle contourne en le faisant, c'est ce qu'il faut corriger.
Enfin, l'ancien fichier reste accessible en lecture seule deux semaines, jamais en écriture. Le laisser modifiable, c'est garantir deux sources de vérité et enterrer l'outil.
Sur la partie build, ma stack est Lovable pour l'application et Claude pour la conception et les itérations. C'est avec ça que j'ai construit seule Wavestay et Pulse Outdoor Training Club. La technique n'est plus le facteur limitant depuis un moment : ce qui limite, c'est la clarté du processus qu'on met dedans.
Le test à faire demain matin
Ouvre le fichier partagé le plus utilisé de ta boîte. Regarde trois choses : qui y écrit, à quelle fréquence, et quelles informations y sont recopiées depuis un autre outil.
Si tu vois une double saisie régulière sur un processus qui a un responsable clair, tu tiens ton premier outil métier. Le site, l'appli client et les agents peuvent attendre — ils iront tous plus vite une fois qu'ils auront quelque chose de propre à lire.