Pourquoi ne pas faire Tsuno avec ChatGPT, Notion et Make ?

On peut assembler un prototype convaincant avec ChatGPT, Notion et Make en un week-end. La vraie question vient six mois plus tard : qui entretient les liaisons, qui a le droit de voir quoi, d'où vient chaque information, et que se passe-t-il quand une automatisation s'arrête sans prévenir ? Un assemblage est un projet à maintenir, pas un produit livré.

Le dimanche soir où tout fonctionne

Un dirigeant de trois restaurants passe son dimanche soir à construire quelque chose. Une base de pages pour les procédures, une automatisation qui envoie un message quand une tâche est cochée, et une IA à qui il pose des questions sur le tout. Le lundi, il fait la démonstration à son second de cuisine. Ça marche. La réponse est claire, le message arrive.

Trois semaines plus tard, une commis arrivée lundi demande la procédure de nettoyage de la trancheuse. La page existe en deux versions, l'une copiée depuis un ancien classeur, l'autre modifiée par le chef. L'IA répond avec les deux, mélangées. Personne ne sait laquelle fait foi. Le dirigeant est en déplacement : lui seul sait comment tout cela tient ensemble.

Pourquoi l'assemblage tient en démonstration et casse en service

Le prototype n'a qu'un utilisateur

Dans une démonstration, une personne voit tout. En production, une plongeuse, un chef de partie, un manager de site et un dirigeant ne doivent pas voir la même chose. Les droits par poste et par site sont rarement la première chose qu'on construit, et c'est la plus pénible à ajouter après coup.

La provenance disparaît

Un texte généré a l'air aussi sûr qu'un fait mesuré. Dans un restaurant, la différence compte : une température relevée par un capteur, une température déclarée par un cuisinier et une température déduite d'une moyenne n'ont pas le même poids. Sans étiquette de provenance, tout se vaut, et la réponse la plus fluide gagne.

Personne ne possède la maintenance

Chaque outil évolue à son rythme : format de données, limites, conditions d'accès. L'assemblage dépend de leurs compatibilités. Le jour où une étape change, la chaîne casse souvent en silence. Et dans un groupe de 30 à 80 salariés, le dirigeant n'a pas le temps d'être le service informatique.

Une action sans garde-fou

Faire envoyer un message ou créer une tâche automatiquement est facile. Décider ce qui part, à qui, avec quel résumé de l'effet et quelle trace de la confirmation, demande une vraie conception. Sans cela, une erreur d'interprétation se transforme en consigne envoyée à toute une équipe.

Ce que le prototype montre et ce qu'il laisse dans l'ombre

Question	En démonstration	Au bout de six mois
Qui voit quoi ?	Tout le monde voit tout	Il faut des droits par poste et par site
D'où vient la réponse ?	Elle semble plausible	Il faut savoir si c'est mesuré, déclaré ou déduit
Que fait-on si la donnée manque ?	L'IA complète	L'outil doit dire qu'il ne sait pas
Qui répare ?	Son auteur	Quelqu'un d'identifié, avec un remplaçant
Qui confirme une action ?	Personne	Un humain, avec trace
Que devient l'historique ?	Écrasé par la dernière modification	Daté et consultable

Comment décider sans idéologie : un test en six étapes

1. Écrivez le cas d'usage en une phrase. Par exemple : « Quand un manager change une procédure, les checklists du poste concerné suivent. » Si vous ne pouvez pas l'écrire, le projet est trop flou.
2. Listez les personnes qui doivent pouvoir lire et celles qui doivent pouvoir modifier. Faites-le par poste, pas par prénom. Sur un tableur, en dix minutes.
3. Choisissez trois questions réelles que vous posez chaque semaine (par exemple « qu'est-ce que mes managers n'ont pas traité ? ») et vérifiez que l'assemblage répond avec ses sources.
4. Cassez volontairement une étape. Coupez une automatisation et notez combien de temps il faut pour s'en apercevoir. Si c'est « quand quelqu'un se plaint », c'est votre réponse.
5. Nommez le mainteneur et son remplaçant. Avec leurs heures dédiées. Une maintenance « quand on a le temps » n'existe pas.
6. Chiffrez le temps réel, pas seulement l'abonnement : construction, correction, formation des managers, explications aux nouveaux.

Erreurs fréquentes

• Confondre démonstration et déploiement. Le premier se juge en dix minutes, le second sur la durée.
• Donner à l'IA le rôle de source de vérité. Elle reformule. La vérité doit venir d'une base datée, attribuée, où l'absence d'information est visible.
• Ouvrir tous les droits « pour aller vite ». On ne les refermera jamais.
• Automatiser une action avant d'avoir décidé qui confirme. Rien ne doit partir sans validation humaine.
• Oublier que le départ d'une personne laisse l'assemblage orphelin. C'est exactement le problème qu'on voulait résoudre pour les consignes.

Ce qu'il faut mesurer

• Le temps de réparation : combien de jours s'écoulent entre une panne d'automatisation et le moment où quelqu'un la remarque ?
• Le taux de réponses sourcées : sur dix questions posées, combien indiquent d'où vient l'information et quand elle a été saisie ?
• Le temps de maintenance par semaine, noté honnêtement pendant un mois, par la personne qui s'en occupe.

Où Tsuno intervient

Tsuno ne prétend pas que l'assemblage est impossible. Il propose le travail déjà fait : ce que vous répétez est écrit une fois, attribué à un poste, transmis par les checklists, la formation et l'accueil. Chaque fait porte sa provenance (mesuré, déclaré, prouvé, observé, déduit, absent), et quand la donnée manque, Tsuno le dit. Vous l'interrogez en langage courant, depuis Tsuno ou depuis votre IA. Il prépare l'action, en résume l'effet, et l'humain confirme. Vos données restent à vous, avec export possible. Pour voir comment cela s'articule avec le reste, lisez la page solution.

Vous gardez aussi vos outils existants : lisez Tsuno remplace-t-il Skello, Combo ou votre logiciel HACCP ? pour savoir quoi conserver.

Comment poursuivre

La question de fond est traitée dans Faut-il vraiment un logiciel de plus dans un restaurant ?. Pour évaluer n'importe quel outil, y compris le vôtre, voyez comment savoir si un logiciel vous fera gagner ou perdre du temps. Et si vous hésitez sur la mise en route, le livré rempli montre ce que l'onboarding évite.

À retenir

Construire est amusant, entretenir est un métier. Avant de décider, testez les droits, la provenance, la panne et la confirmation humaine : c'est là que se joue la différence entre un prototype et un outil de service. Sur l'interface elle-même, voyez parler à son restaurant : gadget ou nouvelle interface ?.