🤖 Gestion de commandes par IA : MakerFlow ⚡ (2026)

Quand les commandes sont dispersées entre les canaux

Les petites structures ne reçoivent pas toujours leurs commandes dans une boutique en ligne bien tenue. On échange avec les clients par messagerie, via les réseaux sociaux, au téléphone, ou directement dans l'atelier. Chaque canal marche, mais aucun ne garantit, à lui seul, d'avoir une "source unique" pour suivre le travail.

Résultat : les détails finissent éparpillés. On retrouve, selon les messages, le nom du client, ses coordonnées, le produit, la quantité, la matière, la couleur, les dimensions, le prix, l'acompte, le solde et la date souhaitée. Puis il faut tout retrouver au moment de fabriquer, d'encaisser ou d'organiser le retrait. Une feuille de calcul peut aider, mais elle oblige à recopier. Des notes séparées, elles aussi, sont faciles au début - et vite pénibles quand les commandes s'accumulent.

Le souci n'est pas seulement la saisie. C'est l'absence de fil continu entre la demande initiale, le devis, la production et la remise du produit. Quand chaque étape vit dans un outil différent, le propriétaire devient le "système d'intégration".

Une petite application plutôt qu'une plateforme complète

MakerFlow s'adresse aux artisans indépendants et aux petites entreprises qui veulent un bureau de commandes simple, sans la complexité d'une plateforme e-commerce ou d'un logiciel de production lourd. Le projet a notamment été pensé pour un petit atelier d'impression 3D, où les demandes arrivent souvent sous forme de messages libres plutôt que de formulaires standardisés.

L'application regroupe les informations dans une fiche de commande :

• le nom et les coordonnées du client ;
• l'article, la quantité et ses caractéristiques ;
• le prix, l'acompte et le montant restant ;
• l'échéance et les modalités de retrait ou de livraison ;
• l'état d'avancement de la commande.

Ce périmètre est volontairement limité. MakerFlow ne cherche pas à couvrir toute l'activité d'une entreprise. Il vise une zone de friction précise : transformer une demande informelle en dossier exploitable, puis éviter que le suivi repose uniquement sur la mémoire du dirigeant.

Dans un petit atelier, une application ciblée qui s'intègre au travail réel peut rendre davantage de services qu'une plateforme complète que personne n'a le temps d'alimenter.

C'est important. Ajouter la facturation, les stocks, la comptabilité ou la synchronisation de tous les canaux peut devenir pertinent plus tard. Mais chaque fonction en plus augmente aussi le coût de développement, la charge de maintenance et le nombre de cas à gérer. Souvent, le bon ordre consiste à stabiliser d'abord le flux principal.

Du message libre au brouillon structuré

Le point de départ, c'est un message copié par l'utilisateur dans MakerFlow. Par exemple : « Bonjour, je voudrais trois supports de téléphone noirs, larges de 18 cm, pour 45 €. Je peux les récupérer vendredi. » L'application envoie ce texte à Gemma, via Ollama, pour extraire des champs structurés : article, quantité, couleur, dimension, prix et mode de retrait.

Gemma ne fabrique pas une commande "définitive". Elle produit un brouillon modifiable. C'est un choix de conception important : les messages humains sont parfois incomplets, ambigus ou carrément contradictoires. Une IA peut deviner l'intention, mais elle ne sait pas automatiquement si elle a compris exactement les conditions commerciales.

Dans cet exemple, MakerFlow peut proposer une fiche avec le nom du client (si présent), ses coordonnées, l'article, les spécifications, le prix et les infos de retrait. Si une date précise ne ressort pas clairement, elle ne doit pas être inventée. L'utilisateur complète ou corrige avant d'enregistrer.

Le parcours reste simple :

1. Copier le message du client dans l'application.
2. Demander à Gemma d'en extraire les informations.
3. Relire et corriger le brouillon.
4. Enregistrer la commande validée.
5. Suivre son avancement jusqu'à la remise au client.

La validation humaine, ici, change tout. Sans elle, une erreur d'extraction peut se traduire par une mauvaise dimension, un prix incohérent, ou une promesse de livraison non confirmée. Pour une app qui touche à des engagements commerciaux, l'automatisation totale n'est pas forcément le progrès.

Du brouillon au suivi de production

Une fois la commande enregistrée, MakerFlow permet de suivre l'avancement à travers un parcours défini :

Nouvelle → Devisée → Payée → En production → Prête → Expédiée → Terminée

Ce flux rend visible la prochaine action attendue. Vous pouvez filtrer les commandes parmi les actives, celles en retard, ou toutes les commandes. Les échéances dépassées sont mises en évidence, ce qui aide à repérer ce qui nécessite une intervention avant que le client ne relance.

Le suivi financier fait partie de la même fiche : prix, acompte et solde restant. Ce n'est pas un outil comptable. C'est une vue opérationnelle pour savoir ce qui a été convenu et ce qui reste à encaisser. Ça évite de confondre "suivi de commande" et "tenue des comptes" ou "facturation conforme".

MakerFlow permet aussi d'exporter les commandes en CSV. Ce n'est pas spectaculaire, mais c'est utile : sauvegarde, analyse dans un tableur, ou migration vers un autre outil. Les données ne devraient pas se retrouver coincées dans l'application.

Ce que l'IA fait - et ce qu'elle ne fait pas

Le rôle de Gemma, dans ce projet, est limité à l'extraction d'informations depuis le texte fourni. Le modèle ne décide pas de la production, et il ne contacte pas le client. Il n'a pas à juger si un délai est réaliste, si un prix est rentable, ou si une demande est faisable techniquement.

Cette séparation réduit le risque et simplifie le produit. L'IA fait surtout ce qui fait gagner du temps : mettre en forme une demande. Le propriétaire garde la responsabilité des engagements. C'est souvent plus sûr que de laisser une IA exécuter des actions autonomes, difficiles à surveiller et à rattraper.

Le code du projet est disponible dans le dépôt GitHub de MakerFlow. L'article de présentation initiale est aussi sur DEV Community.

FastAPI, SQLite et Ollama

MakerFlow s'appuie sur une base technique volontairement légère : Python et FastAPI pour le serveur, SQLite pour stocker les commandes, une interface web en HTML, CSS et JavaScript, et Ollama pour exécuter Gemma 3 4B. Le projet inclut aussi une configuration Docker et Docker Compose pour déployer les composants.

Concrètement, le chemin d'une demande ressemble à ceci :

Navigateur → application FastAPI → Ollama → Gemma

Le serveur envoie le message à Gemma et récupère une réponse en JSON. Ensuite, il normalise certains champs (prix, devise, date), fixe le statut initial de la commande, puis renvoie le brouillon au navigateur. Après correction par l'utilisateur, FastAPI valide les champs - notamment les montants - et enregistre la commande dans SQLite.

Dans la configuration décrite, l'application et Ollama tournent dans des conteneurs séparés, reliés via un réseau Docker privé. La base de données et les fichiers du modèle utilisent des volumes persistants. Le déploiement peut se faire sur un serveur privé (par exemple une machine virtuelle chez un fournisseur cloud) ou sur une infrastructure contrôlée par l'entreprise.

Donc, oui, il faut être précis sur le mot "local". "Local" ne veut pas forcément dire "sur l'ordinateur de chaque artisan". Ici, l'idée est plutôt d'exécuter le modèle sur une infrastructure sous contrôle, sans passer par une API d'IA externe à chaque message. Un serveur distant privé reste distant : il faut gérer l'administration, l'accès et la sécurité.

Les avantages d'un modèle hébergé par l'entreprise

Utiliser Gemma via Ollama peut intéresser une petite structure, pour des raisons assez concrètes :

• Des coûts plus prévisibles : pas de facturation au message via une API commerciale, même si le serveur et son exploitation ont un coût.
• Un meilleur contrôle des flux de données : les messages restent dans une infrastructure administrée par l'entreprise, sous réserve d'une configuration correcte.
• Moins de dépendance à un fournisseur d'API : le modèle ou l'infrastructure peuvent être remplacés si le besoin change.
• Un usage ciblé : le modèle sert à extraire des champs utiles, pas à fonctionner comme un assistant généraliste.

Mais rien de tout ça n'est automatique. Héberger soi-même un modèle ne garantit pas la confidentialité, ni la conformité au RGPD. Il faut quand même contrôler l'accès à l'application, sécuriser le serveur, organiser les sauvegardes, définir une durée de conservation et préciser ce qu'on fait avec les demandes d'accès ou de suppression.

Un message client peut contenir un nom, un numéro de téléphone, ou d'autres informations personnelles. En France (ou plus largement dans l'Union européenne), il faut donc documenter les traitements, limiter la collecte, et vérifier les obligations liées à l'activité. Le fait que le modèle soit "ouvert" ou "auto-hébergé" ne remplace pas cette analyse.

Les coûts ne disparaissent pas : ils changent de forme

Une API hébergée peut coûter davantage quand le volume de requêtes grimpe. À l'inverse, faire tourner le modèle sur une machine dédiée implique d'autres dépenses : ressources matériel, configuration, et suivi. Il faut aussi prévoir le temps pour maintenir les conteneurs, mettre à jour le système, surveiller les pannes et vérifier les sauvegardes.

Pour un atelier qui traite quelques commandes par semaine, un service hébergé peut rester plus simple. Pour une entreprise qui manipule des données sensibles, qui veut maîtriser l'hébergement ou qui a un volume plus stable, une infrastructure privée peut valoir le coup. Le bon choix dépend du coût total, pas juste du prix "par requête".

SQLite mérite aussi d'être évalué selon l'usage. C'est pratique pour une application légère : facile à déployer, facile à sauvegarder. Mais si plusieurs personnes travaillent en même temps, si l'activité s'étend sur plusieurs sites, ou si la disponibilité devient critique, il faudra reconsidérer le stockage et l'architecture. Ce n'est pas "un défaut" du choix initial : c'est un compromis adapté à un périmètre.

Un outil adapté à un flux de commandes informel

MakerFlow convient quand les commandes nécessitent des échanges (donc pas des formulaires figés), tout en restant assez répétitives pour suivre un schéma commun. C'est typiquement le cas pour un atelier d'impression 3D, un artisan qui fabrique sur commande, ou une activité de création qui reçoit des demandes via messagerie.

En revanche, c'est moins évident pour une entreprise qui a déjà une boutique en ligne avec un processus intégré, ou pour une structure qui a besoin de stocks avancés, de facturation, de comptabilité, de planification complexe ou de gestion multi-utilisateur. Dans ces cas-là, ajouter une application isolée risque d'ajouter un outil de plus au lieu de réduire la friction.

Avant de développer ou d'adopter quelque chose de similaire, regardez le travail réel pendant quelques semaines. Notez les infos qu'on oublie le plus souvent, le temps perdu à recopier, et les erreurs qui entraînent des retards. Si le problème ne touche que quelques commandes par mois, un formulaire ou un tableur bien pensé peut suffire. Si messages et suivis prennent du temps tous les jours, l'automatisation devient plus intéressante.

Évaluer le gain sans confondre démonstration et produit fini

Pour savoir si l'outil apporte de la valeur, mesurez des indicateurs simples : temps moyen entre la réception du message et la création de la fiche, nombre de commandes incomplètes, retards repérés à temps, et temps passé à retrouver une information. Surveillez aussi le taux de corrections nécessaires : si chaque brouillon doit être refait entièrement, le gain réel n'est pas encore là.

Un projet présenté dans le cadre d'un défi de développement montre une approche et un périmètre fonctionnel. Mais ce n'est pas, à lui seul, une preuve que tout est prêt pour une utilisation en production. Avant de l'adopter, vérifiez notamment la gestion des comptes utilisateurs, les permissions, les sauvegardes et restaurations, la sécurité du serveur, la politique de conservation des données, et ce qui se passe en cas d'erreur du modèle.

Le modèle économique mentionné pour MakerFlow reste aussi une piste : abonnement mensuel modeste, prestation de configuration, ou version adaptée à un atelier. Chaque option a ses contraintes. Un abonnement implique support, disponibilité et mises à jour. Une prestation ponctuelle peut convenir à un besoin spécifique, mais c'est moins simple à réutiliser. Une version personnalisée peut coller à votre réalité, mais demande plus de suivi.

Au final, la règle est pratique : la valeur générée doit dépasser le coût de l'outil et le temps nécessaire pour le faire fonctionner. Si l'IA fait gagner quelques minutes mais ajoute des vérifications, des incidents ou une dépendance technique trop lourde, elle n'a pas vraiment simplifié le système. Si elle réduit la saisie répétitive tout en laissant la décision à la bonne personne, alors elle tient son rôle.