Étude de cas Speed Move
Speed Move reçoit ses commandes par e-mail, sur une adresse d'exploitation dédiée. Rien d'inhabituel. Ce qui l'était davantage, c'est le parcours que chaque commande devait accomplir avant d'exister réellement dans le système. L'opérateur ouvrait Outlook et triait les messages entrants pour isoler les commandes. Il basculait ensuite sur la GED, cliquait sur « commandes à saisir », recherchait le message correspondant, l'ouvrait. Il lui fallait alors trancher une question qui ne figurait nulle part dans le document : cette commande relève-t-elle de l'affrètement ou de la saisie classique ? La réponse dépendait de la ville de destination, comparée à un référentiel interne où certaines villes apparaissaient en gras et d'autres non — et où certaines n'apparaissaient pas du tout. Ville en gras : saisie classique. Ville absente ou hors référentiel : affrètement, avec une qualification à renseigner dans un menu déroulant. Venait ensuite la double saisie proprement dite. Le tarif et le numéro client dans la GED. En parallèle, la même commande dans Wintrans, le TMS. Puis la récupération du numéro de référence Wintrans généré, sa réinjection dans la GED, et enfin la double validation : « traité » côté GED, validation côté Wintrans. Multiplié par trois à quatre cents, chaque jour.
Le premier enjeu était volumétrique. À ce rythme, la saisie n'absorbait pas une partie du temps de l'exploitation : elle en constituait l'essentiel. Toute variation de charge — un pic saisonnier, une absence — se traduisait mécaniquement par du retard sur l'ensemble du flux. Le deuxième enjeu était celui de la connaissance implicite. La règle de distinction entre affrètement et saisie classique n'existait sous forme écrite nulle part. Elle vivait dans un tableau, dans une convention typographique, et surtout dans la tête des personnes qui l'appliquaient depuis des années. Une telle règle ne se documente pas spontanément : elle se reconstitue, en observant ceux qui l'appliquent. Le troisième enjeu était l'intégration. Automatiser la saisie sans se connecter à Wintrans n'aurait produit qu'un déplacement du problème. La solution devait écrire dans le TMS, pas à côté.
Observation du poste réel. Coekipia n'a pas demandé de procédure : nous avons regardé travailler. Chaque clic, chaque hésitation, chaque cas où l'opérateur s'écarte du chemin nominal a été relevé. C'est cette phase qui a fait apparaître le référentiel de villes et la règle du gras — invisible dans toute description théorique du processus. Formalisation des règles métier. Nous avons transformé la connaissance implicite en règles explicites et testables : conditions de bascule vers l'affrètement, traitement des villes absentes du référentiel, cas d'exception à remonter en validation humaine. Cette formalisation a été relue et corrigée par l'exploitation avant tout développement. Cadrage des accès. Trois accès conditionnaient le projet : Outlook, la GED et Wintrans. Coekipia les a identifiés et demandés dès le cadrage, avec un environnement de test dédié. Un projet d'automatisation qui découvre ses contraintes d'accès en cours de développement prend systématiquement du retard. Développement en trois semaines. Construction du connecteur mail, du moteur de règles, de la double écriture GED / Wintrans et de l'interface de contrôle. Mise en service accompagnée. Fonctionnement en double avec les opérateurs sur les premiers jours, puis bascule progressive.
La boîte d'exploitation est surveillée en continu. Chaque commande entrante est extraite et structurée : client, destination, références, quantités, tarif. Le moteur de règles applique ensuite la qualification affrètement ou saisie classique à partir du référentiel de villes, désormais maintenu comme une donnée du système et non plus comme une convention de mise en forme. La commande est créée dans Wintrans, la référence générée est récupérée, et la GED est renseignée avec le tarif, le numéro client et cette référence. Les deux validations sont posées. Ce qui ne rentre pas dans les règles ne passe pas en force. Les cas ambigus — ville inconnue, incohérence tarifaire, champ manquant — sont routés vers une file d'exceptions présentée à l'exploitation, avec le motif du blocage. L'opérateur tranche, et son arbitrage alimente le référentiel.
Quatre cents commandes traitées automatiquement, chaque jour. L'exploitation ne saisit plus : elle arbitre les cas qui méritent un arbitrage.
Autres projets
Noté 5 Préparer deux commandes distinctes pour deux clients distincts, en un seul passage, sur un parcours unique, avec deux palettes montées simultanément et une contrainte de hauteur à respecter. Chez CMP, cette opération existait déjà — dans la tête des préparateurs les plus expérimentés. Coekipia l'a rendue systématique, calculable et guidée.
Noté 5 Dans une entreprise de mécanique de précision de moins de dix personnes, le chiffrage est assuré par ceux qui, précisément, n'ont pas de temps à lui consacrer. Chez SC MECA, à La Grand-Croix dans la Loire, Coekipia a développé sept modules qui transforment un plan en devis argumenté.
Noté 5 Sur une ligne d'extrusion qui tourne en continu, la relève est le moment où l'information a le plus de chances de se perdre. Chez Leygatech, Coekipia a commencé par un diagnostic IA global, puis développé l'outil qui manquait réellement : une application atelier de passation de poste et de pilotage de ligne.