ArtisFlow n’est pas né d’une idée de SaaS. Le point de départ était une question beaucoup plus modeste :
Pourrait-on regrouper toutes ces commandes et calculer les totaux dans un tableur ?
L’entreprise était une boulangerie artisanale française qui fournit hôtels, restaurants, commerces et autres clients professionnels. Les commandes arrivaient par téléphone, WhatsApp et e-mail, souvent auprès de personnes différentes. Il fallait ensuite retrouver, interpréter et transmettre ces informations avant le début de la production.
Des commandes pouvaient être oubliées. Les modifications étaient difficiles à suivre. La production commençait souvent sans vision fiable de la demande confirmée. Le problème apparent était le calcul. Le vrai problème consistait à créer une source de vérité unique entre clients, production et livraison.
- 60 à 70 clients B2B
- Plus de 1 000 commandes par mois
- En production depuis octobre 2025
- Produit conçu et construit de bout en bout par une personne
Une activité où chacun travaille selon une horloge différente
Il ne s’agissait pas d’un problème classique de commande B2B. La production commence vers minuit. Les premières tournées partent autour de 5 heures. Les hôtels et le marché ont besoin d’un premier lot tôt le matin ; les restaurants sont généralement livrés plus tard, avant le service du midi. Pourtant, certains restaurants ne transmettent leur commande du lendemain qu’après le service du soir, vers 22 ou 23 heures. Les hôtels peuvent attendre de connaître leur taux d’occupation avant de finaliser les besoins du petit-déjeuner.
Pour la production, la question n’est donc pas simplement « Combien de baguettes ont été commandées ? », mais :
Combien d’unités de chaque produit doivent être prêtes pour chaque créneau de livraison, et quelles quantités correspondent à quel client ?
Avec une centaine de références et 60 à 70 clients professionnels, reconstruire manuellement cette vision à partir de messages n’était pas viable.
Pourquoi Excel ne suffisait pas
Un tableur sait additionner des quantités. Il ne rend pas fiable un processus non structuré auquel participent plusieurs personnes. Il ne détermine pas qui possède la commande originale, si un message a déjà été saisi, s’il s’agit d’une nouvelle commande ou d’une modification, quelle version est la bonne, ni comment gérer commandes hebdomadaires, jours fériés et exceptions.
Améliorer la ressaisie interne aurait toujours obligé quelqu’un à recopier les informations du client. La première décision produit était donc simple :
Ne pas améliorer la ressaisie. La supprimer.
Le client doit rester propriétaire de sa commande structurée d’origine. Les mêmes données peuvent ensuite alimenter toutes les opérations en aval.
Commencer petit : une PWA, un seul flux
J’ai commencé le développement en juillet 2025. La première version était volontairement réduite : une PWA dans laquelle les clients B2B saisissaient eux-mêmes leurs commandes. Produits, quantités et dates de livraison n’entraient qu’une seule fois dans le système.
Le pilote a été mis en production en octobre 2025. Il fonctionne depuis sans interruption, tandis que le produit continue d’évoluer. Aujourd’hui, le flux traite plus de 1 000 commandes B2B par mois.
La première version ne cherchait pas à résoudre tous les problèmes opérationnels. Elle établissait une base fiable : une commande, saisie à la source et disponible dans tout le processus.
L’usage en production a conçu la suite du produit
Le travail produit le plus important a commencé après le lancement.
Une commande répétée ne doit pas imposer un travail répétitif
De nombreux clients B2B commandent régulièrement les mêmes produits. Les favoris évitent des recherches inutiles. Pour la demande prévisible, j’ai ajouté des commandes récurrentes configurables séparément pour chaque jour de la semaine.
Une commande automatique est créée à 8 heures la veille de la livraison. Jusqu’à minuit, le client peut la modifier ou l’annuler. L’objectif n’est pas de lui retirer le contrôle, mais de supprimer le travail répétitif tout en préservant ce contrôle.
Une commande oubliée a besoin d’un filet de sécurité, pas d’un modèle prédictif
L’exploitation réelle a révélé un autre mode d’échec : certains clients ne souhaitent pas de commande quotidienne permanente, mais oublient parfois de commander. Pour un restaurant, découvrir le matin qu’aucun pain ne sera livré constitue un véritable incident opérationnel.
J’ai réutilisé la même infrastructure déterministe pour ajouter une commande de secours. Ce n’est pas une prédiction par IA. Elle n’est créée qu’à minuit, et seulement lorsqu’aucune commande n’existe déjà pour la date de livraison concernée.
Tous les problèmes d’automatisation n’ont pas besoin d’IA. Le mécanisme fiable le plus simple est souvent la bonne décision produit.
L’usage en production a transformé une petite PWA de commande en un flux opérationnel plus large.
Une commande, plusieurs réalités opérationnelles
Une fois la commande d’origine structurée, chaque rôle doit la voir différemment. Le client raisonne en panier. La production a besoin d’une demande agrégée par produit et par créneau. L’emballage a besoin d’informations propres à chaque client et à chaque tournée. La livraison a besoin d’un itinéraire ordonné, de statuts opérationnels et de documents.
ArtisFlow transforme les mêmes données sources en représentations adaptées à chaque rôle :
- La préparation convertit les commandes confirmées en totaux de production, répartis par tournée ou créneau.
- L’emballage reconstruit à partir de ces totaux le travail de remise propre à chaque client et chaque tournée.
- La livraison fournit l’ordre de la tournée, les statuts et les documents utiles.
Personne ne devrait avoir à reconstruire une commande simplement parce qu’elle passe de la saisie client à la production ou à la logistique.
La préparation consolide les commandes clients en besoins de production répartis par créneau de livraison.
L’emballage réorganise les mêmes commandes pour la remise physique à chaque client et chaque tournée. Les informations clients ont été anonymisées.
Une clôture claire, avec une issue contrôlée
Jusqu’à minuit, les clients peuvent créer, modifier ou supprimer leurs commandes. À minuit, la commande entre dans le flux de préparation et sa modification par le client est bloquée.
Cette limite protège la planification, sans nier la réalité. Si un client appelle avec une exception après la clôture, un membre autorisé de l’équipe peut encore effectuer une correction manuelle contrôlée.
Automatiser le parcours normal, mais conserver une issue contrôlée pour le monde réel.
La boulangerie continue de prévoir une marge de sécurité. La différence est que cette marge vient s’ajouter à une demande connue et consolidée, au lieu de remplacer des informations manquantes ou dispersées dans des messages.
Une fonctionnalité qui n’a pas démontré sa valeur : les avis
J’ai livré une fonction d’avis, mais son adoption reste faible. La raison n’est pas encore établie. Il peut s’agir d’un problème de visibilité, ou simplement d’un besoin peu important dans cette relation B2B. Une prochaine expérience pourrait proposer une notification après livraison, à un moment plus pertinent.
La leçon est simple : livré ne veut pas dire adopté. Le travail produit continue après la mise en ligne : observer les comportements, ne pas inventer d’explication et tester l’hypothèse suivante.
L’IA est une expérience, pas la fondation
ArtisFlow comporte une fonction conversationnelle de commande et d’assistance opérationnelle, actuellement testée comme pilote contrôlé. Pour la commande principale, l’interface structurée est aujourd’hui plus efficace dans le flux établi.
L’assistant peut transformer une demande en brouillon structuré, mais une confirmation humaine reste obligatoire avant toute action. Il n’est pas présenté comme un agent autonome qui exécute les commandes.
Ajouter de l’IA n’améliore pas automatiquement un processus qui fonctionne déjà. La bonne question consiste à savoir si une interaction par IA est réellement meilleure pour une tâche précise — et cela doit encore être démontré.
Faire évoluer un système en production vers un produit multi-tenant
ArtisFlow passe maintenant d’un flux éprouvé dans une entreprise à une architecture SaaS multi-tenant. Il ne s’agit pas d’une réécriture brutale. La migration avance par endpoint et par capacité, avec comparaison en parallèle, décisions explicites de bascule et possibilité de retour. Le flux opérationnel en production reste la référence pendant que chaque nouvelle capacité fait ses preuves.
La cible est une plateforme capable de servir plusieurs entreprises sans considérer le premier tenant comme le cas par défaut. La migration est en cours : ArtisFlow n’est pas présenté aujourd’hui comme une plateforme multi-tenant entièrement lancée.
Une migration progressive et réversible, d’un flux opérationnel éprouvé vers une plateforme multi-tenant.
Mon rôle
J’ai construit ArtisFlow comme unique responsable produit et technique. Mon périmètre comprend la découverte, l’analyse du processus, la stratégie produit, les choix UX, l’architecture, l’implémentation, le déploiement, le support en production et l’amélioration continue.
J’utilise le développement et la recherche assistés par IA tout au long du travail, mais les décisions produit restent fondées sur la réalité opérationnelle observée.
Six leçons tirées de l’exploitation réelle
- Partir du problème opérationnel, pas de la technologie. La demande initiale ressemblait à un problème de tableur. C’était en réalité un problème de responsabilité, de temporalité et de flux.
- Employer le mécanisme fiable le plus simple. Une commande de secours déterministe était plus adaptée qu’un modèle prédictif.
- Considérer l’usage réel comme de la découverte produit. Favoris, récurrence, exceptions, notifications et commandes de secours ont été façonnés par la production.
- Concevoir l’exception, pas seulement le parcours idéal. Une clôture précise est essentielle, tout comme une manière contrôlée de gérer la réalité après cette clôture.
- Ne pas confondre fonctionnalité déployée et fonctionnalité validée. Les avis comme l’IA ont besoin de preuves de valeur réelle.
- Faire migrer un système vivant par étapes réversibles. La continuité opérationnelle est une exigence produit, pas seulement une contrainte d’ingénierie.
Découvrez ArtisFlow et la boulangerie dont les opérations ont façonné le premier flux, L’Ami du Pain.