Une bonne passation de consignes en production tient en cinq points : ce qui a été produit par rapport à ce qui était prévu, les arrêts et leurs motifs, les défauts et les rebuts, les actions encore ouvertes, et les trois choses à traiter en premier. Le tout se lit en trente secondes et se complète à l'oral.
Une IA peut rédiger ce compte rendu de fin de poste, à une condition : que les chiffres soient calculés par le logiciel à partir des données de production, et que l'IA ne fasse qu'écrire les phrases autour. Elle ne remplace pas la discussion entre les deux équipes. Elle la prépare.
Dans la suite : pourquoi la relève de poste perd autant d'information, ce que doit contenir un bilan d'équipe, l'architecture qui le garde honnête, ce qu'il n'est pas, et comment s'en servir au changement d'équipe.
La relève de poste, deux minutes qui coûtent cher
Il est 13 h 25. L'équipe du matin finit, celle de l'après-midi arrive. La passation se fait près de la machine à café : « la 4 a encore fait des siennes, l'OF du carter est presque fini, attention au lot de barres ». Il y a bien un cahier de consignes, rempli en vitesse à 13 h 20, que personne ne relit vraiment.
Ce qui se perd est toujours le même : l'arrêt de 10 h dont personne n'a saisi le motif, les rebuts de fin de matinée sur la même cote, l'OF qui a pris du retard parce qu'on attendait la matière. L'équipe suivante le redécouvre deux heures plus tard, et refait parfois la même erreur. Donc la relève de poste, qui devrait être le moment où l'information passe, est souvent celui où elle se perd.
Le problème n'est pas la bonne volonté. En fin de poste, le chef d'équipe a la tête dans la dernière heure, pas dans les huit. Il raconte ce dont il se souvient, c'est-à-dire ce qui s'est passé récemment ou ce qui l'a agacé. Les chiffres, il ne les a pas sous les yeux, et il n'a pas le temps d'aller les chercher.
Ce que doit contenir un bon compte rendu de fin de poste
Un bilan d'équipe utile est court. S'il fait une page, personne ne le lit à la relève. Voici les cinq rubriques que je garderais, avec ou sans logiciel.
- Produit par rapport au prévu. Par ordre de fabrication : combien de pièces bonnes, combien prévues, est-ce qu'on est en avance ou en retard. Les OF en retard en premier.
- Les arrêts et leurs motifs. Combien, combien de temps, pourquoi. Et combien d'arrêts n'ont pas de motif : un arrêt non qualifié est une information perdue, autant le dire.
- Les défauts et les rebuts. Sur quelle machine, quel type de défaut, combien. Une concentration (trois rebuts sur la même cote, sur la même machine) compte plus qu'un total.
- Les actions encore ouvertes. L'action corrective lancée hier sur la presse 2, l'intervention de maintenance demandée ce matin. Ce qui est en cours, et ce qui attend quelqu'un.
- Trois priorités pour l'équipe suivante. Pas dix. Trois, classées, chacune rattachée à quelque chose de précis : une machine, un OF, un défaut, une action.
La dernière ligne est la plus importante, et c'est justement celle qu'aucun logiciel ne remplira.
Les chiffres calculés, l'IA ne fait que rédiger : l'architecture qui garde le bilan honnête
Pour faire rédiger ce bilan par une IA, la tentation est de lui donner toutes les données brutes et de lui demander un résumé. C'est la mauvaise méthode : le modèle va additionner, arrondir, oublier une machine, et vous n'aurez aucun moyen de savoir où. Voici l'architecture que je recommande, en cinq étapes.
1. Le logiciel calcule tout, à partir de la base
Les pièces produites, les rebuts, le TRS par machine, les durées d'arrêt, les motifs, les OF en retard, les actions ouvertes : tout est calculé par des requêtes sur les données de production. Le même calcul, refait demain sur les mêmes données, donne le même résultat. Ces chiffres sont affichés tels quels dans le bilan, en tableaux et en graphiques.
2. Le modèle reçoit un résumé compact
Pas les données brutes : un résumé de quelques lignes, déjà trié. Les machines les moins performantes d'abord, des listes coupées aux quelques éléments qui comptent, des nombres entiers, des minutes plutôt que des secondes. C'est moins cher, et c'est plus fiable : moins le modèle a à lire, moins il a d'occasions de se tromper.
3. Les éléments sont passés sous forme de références courtes
Chaque machine, défaut, OF ou action reçoit une référence courte dans le résumé (m1, d2, o3…). Le modèle doit rattacher chacune de ses priorités à l'une de ces références, et le logiciel les retraduit ensuite vers les vrais éléments. Toute référence qui ne correspond à rien est ignorée. Donc le modèle ne peut pas inventer une machine : il ne peut que pointer vers une machine que le logiciel lui a donnée. Et chaque priorité devient un lien vers la fiche concernée.
4. Le modèle rédige, et seulement ça
Ce qu'on lui demande : un titre d'une ligne, deux ou trois phrases (ce qui s'est passé, le point fort, le point faible) et trois actions classées. Quand une phrase cite un chiffre, il le recopie du résumé, et le vrai chiffre est affiché juste à côté, calculé par le logiciel : un écart se voit tout de suite. Si une action déjà ouverte couvre un problème, on lui demande de la citer plutôt que d'en inventer une nouvelle.
5. Le bilan est enregistré, et son coût affiché
Une fois généré, le bilan est stocké. Le relire, le lendemain ou dans un mois, ne coûte rien : on ne rappelle pas le modèle. Si quelqu'un redemande un bilan quelques minutes après le précédent, on lui ressert celui qui existe au lieu d'en payer un second. Et le nombre de tokens consommés est affiché, pour que chacun voie ce que ça coûte. Pour ce travail, un petit modèle peu coûteux suffit : il s'agit de rédiger trois phrases propres, pas de raisonner sur l'usine.
Ce que ce bilan n'est pas
- Pas un remplacement de la passation. Le bilan prépare la discussion entre les deux équipes, il ne la supprime pas. La relève reste un moment où l'on se parle.
- Pas une source de chiffres. Les chiffres de référence sont ceux calculés par le logiciel, affichés à côté. Si une phrase et un chiffre ne disent pas la même chose, c'est le chiffre qui a raison.
- Pas une analyse de causes. Le bilan peut dire que la presse 2 a perdu deux heures sur un motif « réglage ». Il ne sait pas pourquoi le réglage ne tient pas. Ça, c'est le travail de l'équipe, devant la machine.
- Pas plus juste que les données. Si les arrêts ne sont pas qualifiés et que les rebuts sont déclarés en fin de semaine, le bilan sera vide ou trompeur. Une IA ne rattrape pas des données absentes. Commencez par faire saisir les motifs d'arrêt simplement, au poste.
- Pas au courant de ce qui n'est pas dans le logiciel. La machine qui fait un bruit inhabituel, la matière d'un nouveau fournisseur, l'intérimaire qui découvre le poste : personne ne l'a saisi, donc le modèle ne le sait pas.
Mode d'emploi : trente secondes devant l'écran, puis on se parle
Le bilan le plus utile est celui qu'on lit au bon moment, au bon endroit. Voici comment je l'organiserais.
- Générer le bilan juste avant la relève, sur la durée de l'équipe : huit heures, par exemple.
- L'afficher sur l'écran atelier, là où les deux équipes se croisent. Pas dans un mail que personne n'ouvre.
- Le chef d'équipe sortant le lit en trente secondes et ajoute à l'oral ce que les données ne peuvent pas savoir : le bruit, la matière, la personne nouvelle, l'outil qui commence à marquer.
- Il corrige si besoin. Si une priorité tombe à côté, il le dit. Le bilan est une proposition, pas une consigne.
- L'équipe entrante ouvre les priorités une par une : la machine, l'OF ou le défaut concerné. Et elle commence par là.
Deux conseils pratiques. D'abord, qualifiez les arrêts avant la fin du poste : un bilan dont la première ligne parle de six arrêts sans motif dit surtout que la saisie n'a pas été faite. Ensuite, gardez la même heure et le même endroit tous les jours. La régularité compte plus que la qualité de la rédaction.
Et sans IA ?
Tout ce qui précède fonctionne sans IA. Le modèle de bilan en cinq rubriques se remplit sur papier, ou à partir d'un tableau de suivi. Ce que l'IA apporte, c'est le temps de rédaction : le chef d'équipe n'a plus à transformer des chiffres en phrases en fin de poste, au moment où il est le plus fatigué. C'est utile. Ce n'est pas indispensable. Un bon bilan papier tenu tous les jours vaut mieux qu'un bilan IA que personne ne regarde.
Si vous tenez aujourd'hui ce suivi dans un tableur, les signes qu'il arrive à ses limites sont dans suivi de production sous Excel : limites et signaux. Et pour le tri plus large entre l'IA utile et l'IA gadget, voyez IA en usine : ce qui est utile, ce qui est gadget.
Ce que nous en avons fait dans cleartrak
Je développe cleartrak, donc voici, pour être transparent, comment le bilan d'équipe y fonctionne. C'est l'architecture décrite plus haut, appliquée telle quelle.
Le bilan lit les dernières heures de l'atelier (8 heures, 24 heures ou 3 jours) : états machines, arrêts et motifs, pièces et rebuts, défauts, OF en retard, actions ouvertes. Le logiciel calcule tout en base. Le modèle reçoit un résumé compact avec des références courtes, et rédige un titre, deux ou trois phrases et les trois actions à traiter en premier, chacune reliée à la machine, au défaut, à l'OF ou à l'action concernée. Il peut aussi signaler un écart marquant, par exemple une machine nettement en dessous des autres. Les chiffres et les graphiques du bilan viennent de la base, jamais du modèle.
Ce qui part vers le modèle : ce résumé, avec les noms des machines, des défauts et des articles, les numéros d'OF, les motifs d'arrêt et les intitulés des actions. Le résumé ne comporte ni noms d'opérateurs, ni plans, ni prix.
Le bilan est enregistré : le relire ne consomme aucun token. S'il en existe un de moins de 15 minutes, il est réaffiché au lieu d'être régénéré, avec un bouton pour forcer une nouvelle génération. Le nombre de tokens consommés s'affiche à côté de chaque bilan. Le dernier bilan apparaît aussi en bandeau sur l'écran atelier en temps réel, là où se fait la relève. Si l'IA n'est pas activée, le bilan est simplement indisponible, et le suivi de production fonctionne exactement pareil. Les principes sont détaillés sur la page intelligence artificielle.
Si vous voulez voir ce que ça donne sur un atelier qui tourne : 20 minutes sur site, vous me montrez votre suivi actuel, je vous montre l'équivalent en temps réel, bilan compris. Prendre ces 20 minutes.
Et que vous preniez cleartrak ou non, gardez l'idée : les chiffres viennent des données, les phrases peuvent venir d'une IA, et la relève reste une conversation. C'est ce qui permet à l'équipe suivante de prendre son poste tranquille.
