• Encore plus grave, la génération de risques de type HSE. Une programmation mal contrôlée peut aboutir de fait à l’existence d’une combinaison logique inextricable dans le système et, en cas de défaut d’un capteur, à créer une situation de danger effective et non a priori détectée. Que l’on songe aux accidents survenus récemment sur des avions de ligne par exemple. Le génie chimique n’en est pas non plus à l’abri.

• Heureusement les soucis sont souvent moins graves mais néanmoins pénalisants, eu égard par exemple à la productivité attendue : combien d’opérateurs ont eu par exemple la très mauvaise surprise de découvrir qu’un équipement, qu’ils pensaient pourtant en situation d’être utilisé, était verrouillé par le système pour des raisons incompréhensibles dans la logique de l’opérateur. Et en effet c’est la plupart du temps l’opérateur qui a raison dans sa logique contre le système. Une analyse mal faite conduit à allouer des équipements ou des parties d’équipements trop largement et à empêcher un parallélisme des tâches de l’opérateur, source de baisse de productivité parfois très importante.

“Celui qui ne sait d’où il vient ne sait pas non plus où il va.”
Cet aphorisme souvent entendu a, dans le cas d’un automatisme deux types de conséquences :

• Ne pas savoir d’où l’on vient se manifeste directement par l’impossibilité de prédire le comportement précis du système une fois en fonctionnement. On objectera qu’on aura pourtant dûment qualifié le système. Certes, mais quasiment jamais pour prendre en compte les situations de dysfonctionnement potentielles. “C’est impossible d’aller jusque-là” s’écrient ceux qui ne possèdent ni l’expérience ni la méthodologie pour traiter correctement le problème. L’insuffisance de la spécification se manifestera donc par de très redoutables approximations, flous, impasses et imprédictibilité de comportement dans la vie réelle.

• Se tromper peut-être fécond à condition d’apprendre de ses échecs. L’histoire des systèmes informatiques nous montre que c’est rarement le cas, et l’automatisation est une branche spécifique de l’informatique. Après un échec on change souvent de fournisseur, sans remettre en cause le déroulement du projet qui est très majoritairement la véritable cause des problèmes.

“Donnez et vous recevrez” (La Bible, Luc) : la proposition contraposée, comme diraient les logiciens, étant : celui qui ne donne rien ne recevra rien. Cet autre aphorisme-là s’applique redoutablement et fréquemment à l’automatisation. Une insuffisance d’information peut compromettre les plus grands et parfois les plus coûteux des projets. Je me rappelle ces deux exemples emblématiques.

Soit donc un nouvel atelier de chimie à automatiser, avec un système spécifique à développer comme toujours dans un atelier de chimie où seuls quelques skids arrivent avec leur automatisme propre. Soit aussi l’ambition d’utiliser le système de conduite de manière à ce qu’il puisse apporter une aide précise et rapide à la libération des lots. Soit alors la question posée par l’automaticien au responsable Assurance Qualité assigné au projet : “quels sont les paramètres critiques à prendre en compte dans la conduite ?”. Et soit alors cette réponse, qui traduit un mélange subtil d’incompétence et une forme d’exonération de ses responsabilités : “moi, je ne rentre pas là-dedans, tout ce que je demande c’est que le système soit BPF”. Cela se passait à l’aube de ce siècle mais il n’est pas sûr que ce type de réponse, malgré la mise en place progressive de l’analyse de risques, ne se rencontrerait plus aujourd’hui. Comment s’étonner alors que le système qui en soit résulté n’ait jamais été capable de fournir plus que quelques enregistrements à examiner en superposant sur le papier une règle transparente… comme 20 ans plus tôt.

Parfois, plutôt qu’un refus, c’est une autre réponse, toute aussi annonciatrice de moments douloureux : “On verra au démarrage…” Et en effet on voit… Je me rappelle cet exemple emblématique, celui de la mise en place d’un très gros système dans un atelier de chimie tout neuf, pilotant plus de 20 000 entrées / sorties. Le recueil du besoin avait été tellement lacunaire que ce ne sont pas moins d’une quinzaine de programmeurs, assis à côté des opérateurs, qui ont dû entièrement réécrire le programme sur une durée d’environ 6 mois.

“Le fournisseur n’a pas demandé un euro de plus pour cette prestation” m’annonça-t-on en forme d’exonération. Certes, mais soyons certains qu’il avait pris grand soin, connaissant son client, d’intégrer ces coûts à l’avance. Et n’oublions pas le temps de mise sur le marché du produit, un blockbuster de la société, autrement plus dommageable que le coût des programmeurs. En effet, au démarrage…on avait vu !
La critique est aisée dira-t-on et l’art est difficile, on le sait. Pour autant elle reste pertinente. Mais il faut se garder de stigmatiser l’automaticien ou du moins de le désigner comme responsable unique des problèmes qui surviennent. On l’a vu, l’absence d’une connaissance suffisante du process à automatiser est une situation courante : développement du process insuffisant, rétention de l’information souvent inconsciente, mais surtout, surtout, manque de méthodologie.

“Ce qui se conçoit bien s’énonce clairement” (Boileau).
La maxime s’applique à plusieurs titres au recueil des besoins de l’utilisateur. Les choses commencent le plus souvent bien lorsqu’il s’agit de décrire le comportement du système, c’est à dire en l’absence de survenue de défaut, soit assez rapide à décrire. Mais il en va tout autrement dès qu’il s’agit de décrire le comportement attendu en présence de défaut. C’est là le point d’achoppement le plus fréquent, c’est là que l’on entend le plus souvent la phrase terrible “on verra au démarrage”, c’est là que l’on s’apprête à rentrer dans un labyrinthe inextricable au moindre défaut, avec des passages en mode manuel intempestifs, non tracés et qui se terminent parfois par des pertes de production et souvent par des appels à l’astreinte lorsqu’il n’est pas encore trop tard.
Il faut savoir que, pour une application bien faite, le volume du programme destiné à traiter les défauts est plus du double de celui qui traite le comportement standard. On comprend alors combien une analyse lacunaire peut hypothéquer l’avenir d’un système.

• Et seulement en cas de problèmes d’élégantes pages de type P&ID qui lui permettront de visualiser où se localise le problème. L’opérateur les utilisera d’une façon anecdotique mais la maintenance y passera la majorité de son temps de connexion.

5. La mise en œuvre matérielle

La mise en œuvre, d’un point de vue du support matériel ne demande que des moyens très réduits : un automate standard fait aujourd’hui l’affaire pour traiter un atelier conséquent. Un superviseur parmi ceux que l’on trouve dans la plupart des ateliers conviendra pour la partie IHM. Paradoxalement les grands systèmes que l’on rencontre en chimie ne s’adaptent guère à cette approche : conçus prioritairement pour l’industrie du “continu” (pétrole, gaz, énergie) ces systèmes ne réalisent que moins de 5 % de leurs chiffres d’affaire respectifs dans l’industrie du batch (discontinu). Pour cette raison, et malgré les dénégations énergiques de leurs promoteurs, ils y sont conceptuellement mal adaptés, quelle que soit la méthode. Si on arrive à “en faire quand même quelque chose” c’est au prix d’investissements et d’astuces qui laissent perplexes devant les approches alternatives.

Conclusion

La méthodologie décrite est mise en œuvre dans la pharmacie, la chimie, l’agroalimentaire ou la cosmétologie avec une vaste majorité de succès avérés. L’application des règles présentée, très simples, est essentielle. Comme en toute chose, c’est un prérequis du succès.
La réduction des coûts est spectaculairement au rendez-vous, souvent de bien plus de 50 % par rapport aux grands systèmes mentionnés au chapitre précédent. La qualité de l’application obtenue est-elle aussi largement bénéficiaire ?