Planifier des centaines de conducteurs : automatiser les roulements à grande échelle sans perdre le contrôle

Planifier trente conducteurs sur un dépôt est un exercice de rigueur. Planifier trois cents conducteurs sur quatre dépôts, avec plusieurs accords d'entreprise, des habilitations différenciées et une part de sous-traitance, est un exercice d'une autre nature. Ce n'est pas le même problème en plus grand : c'est un problème différent.

Cet article décrit ce qui change au-delà d'un certain volume, et comment automatiser la construction des roulements sans perdre la maîtrise du résultat.

Pourquoi la planification change de nature avec la taille

Trois effets se cumulent quand un effectif de conduite dépasse la centaine de personnes.

La combinatoire devient ingérable manuellement. Le nombre d'affectations possibles croît beaucoup plus vite que l'effectif. À trente conducteurs, un planificateur expérimenté trouve une solution acceptable en quelques heures, et surtout il sait pourquoi elle est acceptable. À trois cents, il trouve une solution qui tient, sans être en mesure de savoir si une meilleure existait à quelques pour cent près. La différence n'est pas la compétence, c'est l'espace de recherche.

Les dépôts cessent d'être indépendants. Tant que chaque dépôt planifie de son côté, les ressources ne circulent pas et les tensions ne se compensent pas. Un dépôt en sureffectif ponctuel coexiste avec un dépôt en tension le même jour, sans que personne ne dispose de la vision consolidée qui permettrait de rapprocher les deux. Le coût de cette non-mutualisation est invisible parce qu'il n'apparaît dans aucun tableau de bord.

Le cadre social se fragmente. Les grands réseaux accumulent les historiques : accords d'entreprise différents selon l'origine des équipes, usages locaux consolidés au fil des années, statuts hérités de reprises de contrats. Une règle valable sur un dépôt ne l'est pas nécessairement sur le suivant, et cette hétérogénéité est rarement documentée en un seul endroit.

Les quatre familles de contraintes qui se croisent

La difficulté ne vient pas d'une contrainte prise isolément mais de leur intersection. Un roulement doit satisfaire simultanément quatre familles de règles.

Le cadre réglementaire. Durées maximales de conduite et de service, amplitude, coupures, repos quotidiens et hebdomadaires. Non négociable, et directement opposable en cas de contrôle.

Le cadre conventionnel et local. Dispositions de branche, accords d'entreprise, usages propres à chaque dépôt. C'est la couche la plus difficile à modéliser, parce qu'elle est en partie non écrite et qu'elle repose sur la mémoire des équipes.

Les compétences et habilitations. Permis et FCO à jour, formations spécifiques, connaissance de lignes particulières, aptitude à certains matériels. Une affectation réglementairement conforme peut être opérationnellement impossible.

L'équité perçue. Répartition des services difficiles, des week-ends, des amplitudes longues. C'est la contrainte la moins formalisée et celle qui génère le plus de contestation quand elle est mal traitée.

Un outil qui optimise sur les deux premières familles en ignorant les deux dernières produit des plannings mathématiquement valides et socialement rejetés.

Ce que l'automatisation fait bien, et ce qu'elle ne doit pas faire

L'automatisation est très efficace sur trois tâches. Générer des combinaisons conformes en explorant un espace de solutions qu'un humain ne peut pas parcourir. Vérifier en continu que chaque affectation respecte l'ensemble des règles actives. Recalculer rapidement l'impact d'un aléa sur le reste de la semaine, ce qui est le vrai gain au quotidien.

Elle ne doit pas décider seule, pour trois raisons.

D'abord, une partie des règles réelles n'est pas modélisable : un arbitrage individuel, une situation personnelle, un engagement pris oralement six mois plus tôt. Ensuite, l'acceptabilité sociale repose sur le fait qu'un responsable identifiable assume le planning, pas un algorithme dont personne ne peut expliquer le raisonnement. Enfin, une optimisation poussée à l'extrême produit des plannings sans marge, donc fragiles au premier arrêt maladie.

Le bon partage est celui-ci : la machine propose et vérifie, le planificateur arbitre et signe. Ce qui suppose deux capacités très concrètes dans l'outil. Pouvoir forcer une affectation en gardant la trace de la dérogation et de son auteur. Et voir explicitement quelle règle une modification manuelle vient enfreindre, avant de la valider.

Multi-dépôts : centraliser les règles, décentraliser l'exécution

Le réflexe naturel est soit de tout centraliser dans une cellule unique, soit de laisser chaque dépôt autonome. Les deux extrêmes échouent : la centralisation totale perd la connaissance de terrain, l'autonomie totale interdit toute mutualisation.

Le découpage qui fonctionne sépare la définition des règles de leur application. Le référentiel de règles, les habilitations, les indicateurs et la consolidation sont centralisés. La construction quotidienne, les remplacements et les arbitrages individuels restent au dépôt, au plus près des équipes.

Ce modèle ne tient qu'à une condition : tous les dépôts travaillent sur la même base de données. Deux dépôts qui planifient dans deux fichiers séparés ne mutualiseront jamais, quelle que soit la qualité de leur coordination et la bonne volonté des responsables.

Prouver plutôt qu'affirmer

À grande échelle, la conformité ne se démontre plus par sondage. Il faut pouvoir répondre, pour n'importe quel conducteur et n'importe quelle semaine des mois passés, à trois questions : quel service a-t-il réalisé, quelles règles s'appliquaient à ce moment-là, et si une dérogation a été accordée, par qui.

Cette traçabilité sert dans trois situations : un contrôle réglementaire, un contentieux individuel, une négociation avec les représentants du personnel. Dans les trois cas, un historique complet et horodaté vaut mieux qu'une reconstitution de bonne foi.

C'est aussi le prérequis pour objectiver l'équité. Sans historique consolidé, la répartition des services difficiles reste une impression, et une impression se conteste. Avec l'historique, elle devient un chiffre discutable en réunion.

Comment séquencer le passage à l'échelle

Un déploiement en une seule fois sur l'ensemble des dépôts est un pari inutile. Une progression en quatre phases limite le risque.

Formaliser avant d'outiller. Écrire les règles réellement appliquées, dépôt par dépôt, y compris les usages non écrits. Cette phase révèle presque toujours des divergences que personne n'avait consolidées, et elle a de la valeur indépendamment du projet logiciel.

Traiter un dépôt pilote représentatif. Pas le plus simple : le plus représentatif de la complexité générale. Un pilote trop facile ne prouve rien sur la suite et retarde la découverte des vrais points durs.

Comparer avant de basculer. Faire tourner l'automatisation en parallèle du processus existant sur deux ou trois cycles complets, puis analyser les écarts. Chaque écart est soit une amélioration, soit une règle mal décrite. Les deux enseignements sont utiles.

Étendre, puis consolider. Le gain de la mutualisation entre dépôts n'apparaît qu'après la bascule complète. C'est la dernière étape du projet, pas son argument d'entrée.

Le résultat attendu n'est pas un planning parfait. C'est un planning construit plus vite, dont chaque contrainte est vérifiée automatiquement, et dont chaque écart est documenté. À trois cents conducteurs, c'est cela qui fait la différence entre une organisation qui absorbe les aléas et une organisation qui les subit.