De l’industrie lourde à l’architecture logicielle : leçons de terrain

J’ai grandi au contact des carrières et des installations de concassage de granulats. Je n’y ai jamais été opérateur ni salarié, mais j’ai passé assez de temps près des concasseurs, des cribles, des convoyeurs et des ponts-bascules pour comprendre comment une exploitation lourde fonctionne vraiment. Des années plus tard, en construisant des logiciels pour des entreprises, j’ai compris que le passage des opérations physiques au logiciel est plus court qu’on ne le croit. Les mêmes règles s’appliquent. La matière circule, la capacité est limitée, les intrants varient, les machines cassent, et ce sont des personnes qui font tenir l’ensemble.

Cette note rassemble les leçons que j’ai emportées de cet environnement dans ma façon de concevoir des systèmes. Certaines sont techniques, la plupart ne le sont pas. Toutes viennent de l’observation d’un système physique qui se comporte honnêtement, ce que le logiciel impose rarement.

L’essentiel

• Une ligne de concassage avance à la vitesse de son étage le plus lent. Tout processus d’entreprise aussi.
• La donnée doit être saisie au moment de l’événement physique, une seule fois, par celui qui le voit se produire.
• La panne est normale dans l’exploitation lourde. Un logiciel conçu pour elle doit s’y attendre.
• Passer des opérations physiques au logiciel, c’est concevoir pour la poussière, les gants, le soleil et un réseau mobile faible.

À quoi ressemble une installation de concassage

Pour ceux qui ne se sont jamais tenus à côté d’une installation, une courte description aide.

La roche est extraite au front de taille, en général par abattage à l’explosif, puis chargée dans des tombereaux ou sur un alimentateur. Elle passe d’abord dans un concasseur primaire, souvent un concasseur à mâchoires, qui réduit les gros blocs. Des convoyeurs la portent vers des concasseurs secondaires, parfois tertiaires, qui la réduisent encore. Des cribles vibrants la séparent ensuite par taille en différents produits : sable, graviers de plusieurs calibres, matériaux plus gros pour les fondations et les routes. Chaque produit finit sur son propre stock. Des chargeuses remplissent les camions des clients à partir de ces stocks, les camions passent sur le pont-bascule, et un bon de livraison est imprimé.

L’installation entière est une chaîne. Les articles de Wikipédia sur le concasseur et sur les granulats décrivent les équipements et les produits plus en détail. Ce qu’ils ne transmettent pas, c’est le bruit, la poussière et l’attention constante nécessaire pour que la chaîne continue de tourner.

Leçon 1 : la ligne avance à la vitesse de son étage le plus lent

La première chose qu’enseigne une installation de concassage, c’est que la capacité est fixée par le point le plus étroit. Si le concasseur secondaire traite moins que ce que le primaire lui envoie, la matière s’accumule sur le convoyeur, et le primaire finit par s’arrêter. Accélérer le primaire ne sert à rien. Réparer le secondaire change tout.

Tous les processus d’entreprise que j’ai cartographiés depuis se comportent de la même façon. Les commandes s’accumulent devant la seule personne qui les valide. Les factures attendent le seul document qui arrive en retard. Quand on passe des opérations physiques au logiciel, c’est la première leçon à appliquer : trouver l’étage le plus étroit avant de construire quoi que ce soit. Un système qui accélère une étape qui n’est pas le goulot ne fait qu’allonger la file, comme je l’expliquais dans la note de la semaine dernière sur les dépendances.

Leçon 2 : les intrants varient, et le système doit suivre

La roche n’est pas uniforme. Dureté, taille et humidité changent d’une zone de la carrière à l’autre, et d’un jour à l’autre. Une matière humide colmate les cribles. Une matière dure use plus vite les concasseurs. Une installation qui ne fonctionne qu’avec un intrant idéal ne fonctionne pas.

Dans le passage des opérations physiques au logiciel, les données d’entreprise se comportent pareil. Les clients écrivent mal leur nom, les fournisseurs changent le format de leurs factures, un nouveau collègue saisit un produit avec un nouveau code. Un logiciel conçu pour des données propres échoue dès le premier jour ordinaire. La deuxième leçon du passage des opérations physiques au logiciel est donc de concevoir pour la variation :

• Valider à l’entrée. L’endroit le moins cher pour arrêter une donnée fausse est celui où elle entre, pas trois étapes plus loin.
• Utiliser des listes contrôlées. Produits, clients, sites et véhicules viennent de listes, pas de texte libre.
• Accepter l’exception, mais l’enregistrer. Quand quelque chose ne rentre pas dans le cadre, le système doit le permettre et le signaler, plutôt que de pousser les gens à inventer un contournement.

Leçon 3 : saisir la donnée au moment de l’événement physique

Sur une carrière, le pont-bascule est le moment de vérité. Un camion monte, son poids est enregistré, un bon de livraison est imprimé avec le produit, le client, le véhicule et le poids net. Cet événement unique produit la donnée dont dépendent le stock, la facturation et le transport. Un pont-bascule est, en un sens, l’outil de saisie le plus honnête de l’entreprise : il enregistre ce qui s’est physiquement passé, au moment où cela s’est passé.

C’est devenu l’une de mes règles de conception les plus fermes. Une donnée doit être saisie une fois, au moment de l’événement physique, par la personne ou l’appareil qui le voit se produire. Pas reconstituée en fin de journée de mémoire. Pas recopiée d’un papier vers un tableur par quelqu’un dans un autre bureau. Chaque copie est une occasion d’erreur, et chaque délai est une période pendant laquelle l’entreprise ne connaît pas son propre état.

Passer des opérations physiques au logiciel commence donc par une question : où sont les moments de vérité de cette entreprise, et comment les enregistrer à la source ?

Leçon 4 : les stocks sont des tampons, et les tampons sont un état

Entre le concassage et le chargement, la matière repose sur des stocks. Ils absorbent l’écart entre le rythme de production et le rythme des ventes. Quand la production s’arrête pour maintenance, les ventes continuent sur le stock. Quand une grosse commande arrive, le stock la couvre.

Quand on passe des opérations physiques au logiciel, un stock devient à la fois un tampon et un état. Le système doit savoir combien il y a de chaque produit, ce qui veut dire que chaque entrée et chaque sortie doivent être enregistrées. La production l’augmente. Le chargement le diminue. Transferts, pertes et corrections l’ajustent. Si un seul de ces mouvements manque, le chiffre de stock est faux, et toutes les décisions prises sur ce chiffre le sont aussi.

C’est pourquoi je préfère modéliser le stock comme une liste de mouvements plutôt que comme un nombre que l’on modifie à la main. Le nombre est calculé à partir des mouvements. Quand il est faux, les mouvements montrent pourquoi.

Leçon 5 : les machines s’usent, et la maintenance fait partie du système

Les concasseurs ont des pièces d’usure. Blindages, mâchoires, toiles de crible et bandes transporteuses s’usent à chaque tonne traitée. Une installation qui ignore l’usure tourne bien un moment, puis casse au pire moment. Une installation qui planifie sa maintenance s’arrête selon son propre calendrier.

Cette propriété survit au passage des opérations physiques au logiciel, même si elle est moins visible. Les dépendances vieillissent, les données s’accumulent, les contournements s’empilent. Un système sans plan de maintenance devient fragile, comme un concasseur aux blindages usés. L’industrie mesure la santé de ses équipements avec des indicateurs comme le taux de rendement synthétique, qui combine disponibilité, performance et qualité. Les trois mêmes questions me servent pour n’importe quel système d’entreprise : est-il disponible quand on en a besoin, est-il assez rapide, et ses résultats sont-ils justes ?

Leçon 6 : la panne est normale, il faut concevoir pour elle

Dans l’exploitation lourde, les choses s’arrêtent. Une bande se déchire, un moteur chauffe, le courant coupe, un camion tombe en panne dans la rampe. Personne qui dirige une carrière n’attend une journée sans incident. Ce qui compte, c’est la vitesse à laquelle l’exploitation repart, et le fait que quelqu’un sache ce qui s’est passé.

Tout passage des opérations physiques au logiciel doit partir de cette attente. Quelques principes que j’applique :

• Fonctionner hors ligne quand le réseau tombe. Beaucoup de sites ont un signal mobile faible. Une pesée ou une livraison saisie hors ligne doit se synchroniser plus tard sans être perdue ni dupliquée.
• Enregistrer les arrêts comme des données. Chaque arrêt, avec son heure de début, son heure de fin et sa cause, est une information. Sur plusieurs mois, il montre quelles pannes se répètent.
• Rendre la correction simple. Une saisie erronée doit pouvoir être corrigée par la bonne personne, avec une trace de la correction, pas cachée.
• Ne jamais perdre un enregistrement en silence. Si quelque chose ne peut pas être sauvegardé, l’utilisateur doit le savoir.

Leçon 7 : les spécifications sont des règles, et les règles vont dans le système

Les granulats se vendent sur spécification. Un produit se définit par sa classe granulaire, et les clients, surtout dans le BTP, tiennent à recevoir ce qu’ils ont commandé. Des contrôles comme l’analyse granulométrique le confirment.

Pour un logiciel, les spécifications sont des règles. Chaque produit a un code, une désignation, une unité et des propriétés. Chaque commande fait référence à un produit, pas à une description tapée à la main. Chaque livraison fait référence à une commande. Quand les règles vivent dans le système plutôt que dans la mémoire des gens, les erreurs deviennent plus difficiles à commettre et plus faciles à trouver.

C’est aussi là que le passage des opérations physiques au logiciel profite au client. Un bon de livraison généré à partir de la pesée, de la commande et des règles produit laisse très peu de place à la contestation.

Leçon 8 : des personnes font tourner le système, en conditions réelles

Une carrière n’est pas un bureau. Ceux qui enregistrent les pesées, organisent les départs de camions ou consignent les arrêts travaillent dans la poussière, le bruit, la chaleur et parfois la pluie. Ils portent des gants. Leur écran est parfois un téléphone en plein soleil. Un camion attend et ils n’ont pas le temps de remplir un formulaire en cinq étapes.

Passer des opérations physiques au logiciel, c’est concevoir pour ces conditions. Un logiciel qui les ignore est ignoré en retour. Je conçois donc les écrans de terrain avec cette réalité en tête :

• De grandes zones tactiles utilisables avec des gants.
• Un fort contraste qui reste lisible au soleil.
• Peu de champs par écran, avec des valeurs par défaut sensées.
• Une saisie rapide pour l’action la plus fréquente, comme l’enregistrement d’un chargement.
• Une confirmation claire que l’enregistrement a bien été sauvegardé.

Rien de tout cela n’est de la technologie avancée. C’est du respect pour la personne qui fait le travail.

Un modèle de données qui part du terrain

Quand j’esquisse un système pour une exploitation lourde, je pars des événements physiques, pas des rapports. Le tableau ci-dessous est une illustration simplifiée des enregistrements de base d’un site de granulats.

Enregistrement	Créé quand	Champs clés
Produit	Une fois, par le responsable	Code, classe granulaire, unité, tarif
Client	À la première commande	Nom, identifiants, conditions de paiement
Véhicule	Au premier passage	Immatriculation, transporteur, tare
Commande	Quand le client commande	Client, produit, quantité, site
Pesée	Quand un camion passe sur le pont	Véhicule, brut, tare, net, heure
Bon de livraison	À partir de la pesée et de la commande	Commande, produit, poids net, signature
Mouvement de stock	À chaque production, chargement ou ajustement	Produit, stock, quantité, motif
Arrêt	Quand une machine s’arrête	Équipement, début, fin, cause

Les rapports, tableaux de bord et factures sont ensuite calculés à partir de ces enregistrements. Ce sont des sorties, pas des entrées. Cet ordre de pensée, de l’événement physique à l’enregistrement puis au rapport, est le cœur d’un bon passage des opérations physiques au logiciel.

Ce que la carrière m’a appris des personnes et des décisions

Les leçons techniques du passage des opérations physiques au logiciel sont les plus faciles à écrire. Les plus difficiles concernent les personnes.

Les opérateurs savent des choses qu’aucun rapport ne montre. Ils entendent un roulement sur le point de lâcher. Ils savent quelle partie du front donne une matière humide après la pluie. Un système qui ne leur permet pas d’enregistrer ce qu’ils savent, ou qui les traite comme des opérateurs de saisie plutôt que comme des experts, perd cette connaissance.

Dans l’exploitation lourde, les décisions ont aussi des conséquences visibles. Arrêter la ligne pour maintenance aujourd’hui, ou risquer une panne plus longue la semaine prochaine. Accepter une grosse commande qui vide le stock, ou protéger les clients réguliers. Ces choix m’ont appris que les bons systèmes ne décident pas à la place des gens. Ils leur donnent l’information pour bien décider, puis enregistrent ce qui a été décidé et pourquoi.

Une liste de contrôle pour passer des opérations physiques au logiciel

Avant de dessiner le moindre écran, je parcours ces questions sur le site. Elles résument tout ce qui précède, et elles valent pour une carrière, un entrepôt, une exploitation agricole ou un atelier.

1. Où sont les moments de vérité ? Lister les événements physiques qui créent de l’information : pesée, chargement, réception, production, arrêt. Tout passage des opérations physiques au logiciel commence par cette liste.
2. Qui voit chaque événement se produire ? La personne ou l’appareil le plus proche de l’événement doit l’enregistrer.
3. Quel est l’étage le plus lent ? Le mesurer avant de concevoir quoi que ce soit d’autre.
4. Qu’est-ce qui varie ? Matière, clients, documents, météo. Chaque variation demande une règle ou un chemin d’exception.
5. Qu’est-ce qui casse, et à quelle fréquence ? Arrêts, pertes de réseau, absences. Chaque panne demande un chemin de reprise.
6. Quelles sont les conditions d’usage ? Poussière, gants, soleil, bruit, réseau. Les écrans doivent être conçus pour elles.
7. Quelles sorties comptent ? Bons de livraison, factures, stock, rapports. Elles sont calculées à partir des enregistrements, jamais saisies à part.

Quand ces sept réponses sont écrites, le passage des opérations physiques au logiciel devient surtout une affaire d’exécution soignée. Quand elles manquent, aucune technologie ne compense.

Les erreurs fréquentes

• Concevoir depuis le bureau. Les écrans dessinés derrière un bureau survivent rarement au premier jour sur le site.
• Supposer une connexion permanente. Beaucoup de sites n’ont qu’un signal faible, voire nul, une partie de la journée.
• Saisir en fin de journée. Une donnée reconstituée de mémoire est tardive et souvent fausse.
• Modifier le stock directement. Un chiffre de stock sans mouvements ne peut être ni vérifié ni corrigé proprement.
• Ignorer les arrêts. Un temps d’arrêt non enregistré ne peut pas être réduit.
• Traiter les opérateurs comme des dactylos. Ceux qui sont le plus près des machines en savent souvent le plus sur le système.

Où ces leçons se retrouvent aujourd’hui

Ces leçons expliquent pourquoi je commence chaque projet en demandant ce qui se passe physiquement, et où. Elles ont façonné ma manière de construire des logiciels avec MeskikCode, dont le premier article publié porte justement sur la gestion de stock dans le BTP, et elles ont façonné la méthode en cinq étapes que j’applique à tout le reste. Plus de détails sur ce parcours se trouvent sur ma page de présentation.

Questions sur le passage des opérations physiques au logiciel

Pour aller plus loin

La semaine prochaine, je passe des opérations physiques à l’identité : pourquoi j’ai choisi de ne pas me définir par un seul titre. D’ici là, découvrez mon parcours ou écrivez-moi si vous dirigez une exploitation lourde et souhaitez échanger.