Pourquoi avons-nous construit notre propre système d’exploitation dans le navigateur ?

Si l’on demande, sur un site industriel de taille moyenne, qui travaille avec quel système, on obtient rarement une réponse courte.

La supervision énergétique tourne sur une interface web. Le procédé est piloté par un système SCADA. La maintenance vit dans un autre logiciel — ou encore dans un tableur. Les achats travaillent dans l’ERP. Les alarmes arrivent par e-mail et par téléphone. Et les projets, les contrats et les données de présence ont encore leur propre outil.

Chacun de ces systèmes peut très bien fonctionner, voire de manière excellente, dans son domaine. Le problème ne vient pas forcément d’eux, mais des interstices qui subsistent entre eux.

La décision se perd entre les systèmes

Dans les précédents volets de la série OT, nous sommes plusieurs fois arrivés au même constat : la donnée mesurée n’a pas de valeur en soi. Elle en acquiert lorsque l’écart devient un événement, l’événement une tâche, la tâche un travail réalisé, et le travail un résultat vérifiable par une nouvelle mesure.

Or cette chaîne ne tient presque jamais dans un seul système métier classique.

La mesure naît dans l’un. La décision est prise dans un autre. Le travail est enregistré dans un troisième. La pièce de rechange est commandée dans un quatrième, et le coût est comptabilisé dans un cinquième. À chaque passage de relais, quelqu’un doit copier, rapprocher et se souvenir — ou justement oublier quelque chose.

L’entreprise ne souffre alors souvent pas d’un manque de données. Bien au contraire : la même information existe à cinq endroits, dans cinq états différents.

Quel est le chiffre à jour ? Qui l’a modifié en dernier ? L’intervention a-t-elle eu lieu ? Le problème a-t-il vraiment disparu ? Et qui voit, au fond, l’ensemble du processus ?

Nous ne voulions pas d’une énième application isolée

Nous ne voulions pas répondre à ce problème par un tableau de bord de plus. Une nouvelle application autonome n’aurait fait que créer un îlot supplémentaire.

C’est pourquoi nous avons construit OrigSmart WebOS : un environnement d’exploitation commun, fonctionnant dans le navigateur, pour les activités physiques comme pour les activités de gestion.

On pourrait aussi le dire ainsi : une « couche chapeau » au-dessus de l’écosystème informatique, énergétique et de l’ensemble du patrimoine de données existant de l’entreprise. Les systèmes métier continuent d’assurer leurs propres missions, tandis que WebOS réunit dans un environnement de travail commun les données disponibles, les utilisateurs, les décisions et les processus exécutables.

Ce n’est pas simplement un écran ou un système de menus commun. En dessous, différents systèmes peuvent fonctionner ; au-dessus, une activité d’entreprise cohérente peut être suivie et pilotée. Cette interconnexion demande bien sûr un travail d’intégration : le fait qu’une application apparaisse sur la même interface ne rend pas automatiquement ses données et ses processus communs.

L’appellation « système d’exploitation » ne signifie pas que nous voulons remplacer Windows ou Linux. L’analogie porte sur le modèle de fonctionnement. De même que, sur un ordinateur, le système d’exploitation offre une base commune aux utilisateurs, aux droits d’accès, aux fichiers, aux fenêtres et aux applications, WebOS offre une base commune aux équipements, aux données, aux personnes et aux processus de l’entreprise.

L’utilisateur voit un espace de travail familier, à fenêtres. Il peut ouvrir côte à côte les données énergétiques d’un bâtiment, la tâche de maintenance correspondante, le contrat fournisseur ou le budget d’un projet de construction. Dans les processus interconnectés, il n’a pas à reconstituer manuellement la vue d’ensemble à partir de systèmes distincts, ni à saisir encore et encore les mêmes données.

Pourquoi dans le navigateur ?

Parce qu’aujourd’hui, le navigateur est disponible sur pratiquement tous les postes de travail. Aucun logiciel client distinct n’est à installer, les mises à jour se gèrent de manière centralisée, et l’utilisateur accède au même environnement de travail depuis son ordinateur de bureau, un terminal d’atelier ou — selon ses droits — un appareil mobile.

Mais le navigateur, à lui seul, ne fait pas d’une application un système d’exploitation. Il faut pour cela un modèle de données commun reliant les différentes sources, une gestion unifiée des droits, une collaboration en temps réel et des applications interconnectables.

Qu’est-ce qui en fait plus qu’un logiciel de plus ?

Des sources de données différentes — une interprétation commune

Un fonctionnement unifié ne signifie pas que toutes les données doivent migrer dans une base unique. Les données financières peuvent rester dans l’ERP, les états du procédé dans le SCADA, les mesures dans le système énergétique et les documents dans la GED existante.

Le rôle de WebOS est de les replacer dans un contexte commun. L’identifiant d’équipement d’un système, le centre de coûts d’un deuxième et l’historique de maintenance d’un troisième doivent se rattacher au même équipement réel. Un client, un site, un projet ou un contrat n’est alors plus un ensemble d’enregistrements indépendants les uns des autres, mais un point de référence commun dans l’exploitation.

L’intégration consiste aussi à définir quel système est la source de référence pour quelle donnée, où celle-ci peut être modifiée et comment la modification parvient aux processus liés. Au lieu de tenir à jour à la main cinq copies distinctes, on utilise à plusieurs endroits une seule information, d’origine définie et traçable.

Ce n’est pas qu’une question de confort. Une interprétation commune et des responsabilités clarifiées sur les données réduisent les erreurs d’exploitation dues aux versions divergentes, aux copies manuelles et aux sources de données incertaines.

Travail collaboratif en temps réel

Si deux collègues ouvrent le même document, le même enregistrement ou la même ligne budgétaire, chacun voit les modifications de l’autre. Le système gère le travail simultané et empêche quiconque d’écraser sans s’en rendre compte la modification d’un autre.

Ce même fonctionnement en temps réel relie aussi les personnes au monde OT. Une nouvelle mesure, un changement d’état ou une alarme provenant d’un équipement peut apparaître immédiatement dans l’application, et chez l’utilisateur, auxquels une action est associée.

Travailler ensemble ne signifie alors plus échanger des e-mails et des versions de fichiers séparées, mais s’appuyer sur le même état d’exploitation actuel.

Un accès réglé avec précision

En entreprise, il ne suffit pas de déterminer si quelqu’un a accès à une application. Il importe souvent aussi de savoir quelles données il peut y voir et quels champs il peut modifier.

Dans un projet de construction, par exemple, une personne est habilitée à décider du prix pour le maître d’ouvrage, une autre peut saisir l’offre du sous-traitant, et une troisième peut approuver l’achat. Ils peuvent travailler sur la même ligne, chacun n’accédant qu’aux données et aux opérations nécessaires à son rôle.

OrigSmart WebOS règle cela jusqu’au niveau du champ. Ce n’est pas seulement l’interface qui masque les opérations interdites : les droits sont aussi vérifiés et appliqués côté serveur. Une modification non autorisée est refusée même si quelqu’un contourne l’interface et tente d’appeler directement le back-end de WebOS.

Des organisations séparées, une plateforme commune

Plusieurs entreprises, sites ou clients peuvent utiliser la même plateforme tout en gardant séparées les frontières organisationnelles et d’autorisation de leurs données. Chaque participant voit son propre environnement d’exploitation, tandis que les acteurs centraux habilités peuvent aussi gérer des processus et des reportings consolidés.

C’est particulièrement important pour les prestataires de services, les groupes et les organisations multisites, qui ont besoin des avantages d’une plateforme unique, mais évidemment pas d’un mélange des données.

Extensible, pas à remplacer

Lorsqu’un nouveau besoin métier apparaît, une nouvelle application peut s’appuyer sur les utilisateurs, les droits, les connexions de données et les services communs existants. Inutile de créer à chaque fois une connexion distincte et un environnement applicatif autonome, ou de reconstruire de zéro des intégrations qui fonctionnent déjà.

Et il n’est pas non plus nécessaire de jeter ce qui fonctionne déjà bien. WebOS n’a pas été conçu pour remplacer à tout prix un ERP éprouvé, un système SCADA ou un logiciel de comptabilité. Il peut s’y connecter, reprendre ou transmettre les données nécessaires et gérer la chaîne opérationnelle qui, sinon, se romprait entre les systèmes métier.

Les mêmes données, des décisions différentes

Prenons un exemple simple. La puissance absorbée d’un compresseur frigorifique augmente lentement depuis plusieurs jours.

Dans un environnement fragmenté de manière classique, quelqu’un finit par le remarquer sur une courbe. Il écrit un e-mail. Le technicien de maintenance rappelle pour poser des questions. Le résultat du contrôle atterrit peut-être sur une fiche de travail. La pièce de rechange est commandée dans un autre système. Le coût apparaît plus tard dans un reporting financier — mais entre-temps, le lien entre l’écart mesuré initialement et le résultat économique de la réparation s’est perdu.

Dans un environnement interconnecté avec OrigSmart WebOS, la mesure peut devenir un événement, et l’événement un ordre de travail pour le technicien de maintenance responsable. Le besoin en pièces, l’achat et l’approbation peuvent être rattachés à l’ordre de travail. Après l’intervention, le système peut vérifier si la puissance absorbée est réellement revenue dans la plage normale.

Pour cela, la mesure peut continuer à provenir du système énergétique existant, l’achat peut se faire dans l’ERP, et la tâche peut être traitée dans une application WebOS ou dans un système de maintenance intégré. L’essentiel n’est pas que chaque étape se déroule dans le même logiciel, mais que le lien entre l’écart d’origine, le responsable, l’intervention et le résultat soit préservé de bout en bout.

Chaque acteur voit le même cas sous son propre angle :

• le responsable énergie, l’écart et la courbe de consommation ;
• le technicien de maintenance, la panne, l’historique et la tâche à réaliser ;
• les achats, le besoin en pièces et l’enveloppe approuvée ;
• la finance, le coût et l’impact financier de l’économie ;
• et la direction, tout le parcours du problème, de sa détection jusqu’au résultat vérifié.

Il ne s’agit pas de cinq histoires distinctes, mais de cinq vues du même événement d’exploitation, construites selon les droits et les tâches.

Tout le monde a-t-il besoin d’un WebOS ?

Non.

Sur un petit site où il faut résoudre une seule tâche de mesure et d’alarme, une application ciblée peut suffire. Il en va de même pour une entreprise dont tous les processus essentiels fonctionnent réellement dans un seul progiciel de gestion intégré (ERP), correctement paramétré.

Dans ces cas, les modules OrigSmart — par exemple l’acquisition de données, le comptage ou la gestion des alarmes — peuvent aussi être utilisés seuls, raccordés aux systèmes existants.

Beaucoup d’entreprises industrielles ne fonctionnent toutefois pas ainsi. Chez elles coexistent plusieurs systèmes d’âges et de finalités différents. Pour elles, la vraie question n’est pas de savoir si tout peut être remplacé par un seul grand projet, mais si l’on peut créer, au-dessus de l’écosystème existant, une couche d’exploitation commune, maîtrisée et encore extensible.