Au-delà MES traditionnels : pourquoi l'avenir de l'industrie manufacturière repose sur des solutions natives de la périphérie et axées sur le terrain

La gamme de produits évolue de plus en plus rapidement. Les opérateurs expérimentés quittent l'entreprise et sont remplacés par des employés qui ont besoin d'un accompagnement accru dès leur premier jour. Les données des machines restent enfermées dans des contrôleurs, des systèmes d'archivage ou des logiciels propriétaires que nul autre système ne peut lire facilement.

Même si ces problèmes ne sont pas nouveaux, ils deviennent de plus en plus difficiles à gérer avec des outils dont la configuration prend des mois et dont la modification prend encore plus de temps.

Lorsqu'un ingénieur de procédés doit mettre à jour une consigne de travail, modifier un flux de travail ou ajouter un nouvel attribut de qualité, la réponse d'un système traditionnel consiste généralement à « ouvrir une demande de modification ». Au moment où cette modification parvient à l'atelier, les opérateurs se sont probablement déjà adaptés de manière informelle, ou le moment où le risque existait est déjà passé.

Les délais de déploiement font partie du problème. Un système dont la mise en place prend un an est déjà en retard. Les pratiques opérationnelles évoluent plus rapidement que la plupart des programmes de mise en œuvre, ce qui signifie que les équipes finissent par mettre en service une version du processus qui ne reflète plus la réalité du travail sur le terrain.

Ce sont les ingénieurs des procédés et transformation numérique qui en font les premiers les frais. Ce sont eux qui s'efforcent de combler le fossé entre ce qu'indique le système et ce que font réellement les opérateurs.

Les équipes opérationnelles le constatent à travers la variabilité du débit et le coût lié à la mise à jour des systèmes.

Les responsables informatiques et opérationnels y voient la dette d'intégration qui s'accumule chaque fois qu'une nouvelle source de données ou un nouvel appareil doit être connecté.

La couche d'exécution doit s'adapter au rythme des opérations. C'est la norme à laquelle tout système doit se conformer.

MES traditionnels ont fait leurs preuves dans les ateliers de production.

Ces systèmes ont apporté aux fabricants un atout véritablement précieux : une couche opérationnelle cohérente entre ERP les équipements de production. Des registres de travail normalisés, dossiers de lots électroniques, la traçabilité depuis les matières premières jusqu'aux produits finis, ainsi qu'une documentation prête pour les audits: tout cela provenait de cette couche. Pour les secteurs réglementés en particulier, ce n'était pas une option. C'était le fondement même de la conformité.

Le modèle ISA-95 de niveau 3, qui a façonné la plupart MES traditionnelles, était tout à fait pertinent à son époque. Il offrait aux fabricants un langage commun pour l'intégration entre l'entreprise et les opérations, ainsi qu'un cadre logique pour gérer la planification, la qualité et données de production liaison avec les systèmes métier en amont et les systèmes de contrôle en aval. Cette clarté présentait une réelle valeur opérationnelle.

Ces systèmes avaient également été conçus pour un type d'environnement de fabrication bien précis : des gammes de produits relativement stables, des cycles de changement plus longs, une gestion informatique centralisée et des calendriers de production qui ne variaient pas d'une semaine à l'autre. Dans ce contexte, un système dont la configuration prenait des mois et qui nécessitait l'intervention de spécialistes pour être modifié ne constituait pas nécessairement un handicap. Le rythme des changements était suffisamment lent pour permettre de s'y adapter.

Il est important de le reconnaître. L'intérêt MES moderne ne réside pas dans le fait que les systèmes existants aient été mal conçus. Il tient plutôt au fait que l'environnement de production pour lequel ils ont été conçus a considérablement évolué, et que les principes architecturaux sur lesquels reposent ces systèmes n'ont pas suivi cette évolution.

Les problèmes liés aux anciens MES par le décalage entre le moment où un processus évolue et celui où le système reflète ce changement.

Les cycles de déploiement constituent le principal obstacle. MES traditionnelles MES s'étendent sur plusieurs mois, voire plusieurs années. Au moment où le système est mis en service, le besoin opérationnel qui justifiait son déploiement a souvent évolué. Une nouvelle variante de produit est en cours de production. Une ligne de production a été reconfigurée. Une exigence de conformité a changé. Le système arrive trop tard pour répondre à un problème qui a déjà évolué.

La modification des flux de travail aggrave encore le problème. Dans la plupart des architectures existantes, modifier une étape d'un processus implique d'ouvrir un ticket, d'attendre la réponse d'un fournisseur ou d'un spécialiste interne, et de suivre un cycle de contrôle des modifications qui peut prendre plusieurs semaines.

Ce n'est pas un rythme raisonnable pour un service qui doit constamment s'adapter aux fluctuations de la demande, aux changements de personnel et aux mises à jour techniques. Le goulot d'étranglement, ce ne sont pas les personnes, mais l'architecture.

Connectivité machine suit le même schéma. La connexion d'un nouvel équipement à un MES existant MES généralement traitée comme un projet d'intégration sur mesure, avec son propre périmètre, son calendrier et son budget. Dans les environnements mixtes comprenant des machines plus anciennes, des protocoles différents et des systèmes de contrôle de différentes générations, cette approche n'est pas évolutive. Chaque nouvelle connexion devient une négociation.

Il y a ensuite l’expérience de l’opérateur. De nombreux systèmes hérités ont été conçus pour capture des données, et non pour guider l’exécution des tâches. Il en résulte ce que l’on appelle le « papier sur écran »: un écran qui reproduit un formulaire papier sans pour autant aider l’opérateur à mieux accomplir son travail. Il n’y a ni conseils contextuels, ni retour d’information en temps réel, ni lien entre ce que le système affiche et ce que fait la machine ou le processus. Les opérateurs contournent le système plutôt que de l’utiliser.

Derrière tout cela se cache une dépendance structurelle vis-à-vis des spécialistes. Chaque modification, qu'il s'agisse d'une modification du flux de travail, de l'ajout d'un nouveau champ de données ou d'une mise à jour de la connectivité, nécessite l'intervention d'une personne possédant une connaissance approfondie du système pour être mise en œuvre. Cela engendre des coûts de coordination qui s'accumulent au fil du temps et ralentissent les équipes les plus proches du terrain.

MES natif du cloud a constitué une véritable avancée, et il est important d'en comprendre les raisons avant d'aborder les problèmes qu'il n'a pas résolus.

MES traditionnels déployés sur site MES d'importants investissements en infrastructure, de longs cycles de mise en œuvre et une équipe spécialisée pour gérer chaque mise à jour. Les solutions natives du cloud éliminent bon nombre de ces contraintes.

Les architectures basées sur des API facilitent la connexion MES ERP, les systèmes qualité et d'autres logiciels d'entreprise, sans qu'il soit nécessaire de mettre en place des intégrations point à point personnalisées pour chacun d'entre eux. Les cycles de mise à jour sont plus courts, car vous n'avez pas à attendre que l'équipe informatique locale valide et déploie chaque version. L'extension à plusieurs sites devient alors un problème de coordination plutôt qu'un projet d'infrastructure.

L'analyse, le reporting et les services centralisés sont également plus pratiques. Au lieu de regrouper les données provenant de serveurs sur site isolés, les plateformes natives du cloud peuvent rassembler les données opérationnelles au sein d'une couche commune où elles sont réellement exploitables pour assurer une visibilité inter-sites et permettre une analyse comparative des performances.

Cette évolution s'inscrit également dans la lignée de l'interprétation de plus en plus courante de la norme ISA-95. Le modèle initial décrivait une hiérarchie rigide de niveaux, allant des appareils de terrain jusqu'aux systèmes d'entreprise. MES natifs du cloud MES réorienter le débat sur la norme ISA-95, en la considérant comme un ensemble de limites logiques et d'interfaces flexibles entre les opérations et les systèmes d'entreprise, plutôt que comme une pile figée de niveaux sur site. Il s'agit là d'un cadre plus pertinent pour les environnements de production distribués et multisites.

Mais MES natifs du cloud ont MES résolu les problèmes liés à la coordination et à la couche de services. Ce qu'ils n'ont pas résolu, c'est l'exécution au niveau de la production.

La connexion des machines, des capteurs et des outils aux flux de travail nécessitait encore un travail d'intégration considérable. Les applications destinées aux opérateurs restaient souvent reléguées au second plan dans la plupart des déploiements. Le dernier maillon entre le cloud et le poste de travail restait difficile à franchir, et c'est là que se situent aujourd'hui la plupart des obstacles dans l'industrie manufacturière moderne.

MES natifs du cloud MES l'architecture dans la bonne direction. Mais il subsiste un fossé entre ce que les systèmes cloud font bien et le lieu où la production a réellement lieu.

Cet espace, c'est le terrain. Machines, capteurs, outils, caméras, opérateurs, postes d'assemblage, points de contrôle. C'est là que tout se passe, que les décisions sont prises en temps réel et que les problèmes de latence et de connectivité ont des conséquences concrètes.

Une architecture exclusivement basée sur le cloud peut rencontrer des difficultés dans ce contexte, non pas parce que le cloud n'est pas l'outil adéquat, mais parce que le personnel sur le terrain ne peut pas se permettre d'attendre le temps de latence aller-retour et que la connectivité n'est pas toujours garantie.

L'exécution native en périphérie signifie que le système fonctionne à proximité immédiate de l'activité. La logique s'exécute localement. Les instructions destinées aux opérateurs s'affichent dans leur contexte. Les signaux émis par les machines déclenchent les étapes du flux de travail sans attendre la réponse d'un serveur distant. Lorsqu'une caméra détecte une anomalie ou qu'un capteur dépasse un seuil, la réponse est générée directement sur le poste de travail, sans passer par un aller-retour vers un centre de données.

Il s'agit là d'une distinction importante. La périphérie n'est pas une passerelle que l'on ajoute simplement pour répondre à une exigence informatique. C'est l'environnement d'exécution, la couche où s'inscrivent concrètement le contexte en temps réel et la réactivité des opérateurs.

Le cloud reste essentiel, et ce, à bien des égards. La coordination, l'analyse, la gouvernance, la gestion des déploiements et l'évolutivité sont autant d'aspects qui s'organisent mieux de manière centralisée. Que vous deviez déployer une mise à jour de workflow sur 40 lignes, auditer Données process un contrôle de conformité ou agréger des indicateurs de qualité entre différents sites, l'infrastructure cloud est la solution idéale pour mener à bien ces tâches.

Ces deux niveaux sont complémentaires. Le cloud prend en charge ce qui doit être centralisé. La périphérie gère ce qui doit rester au niveau local. Ensemble, ils permettent de résoudre les problèmes que les architectures exclusivement basées sur le cloud ne peuvent pas entièrement résoudre : la latence sur le terrain, les difficultés d'adoption chez les opérateurs, la connectivité dans les environnements existants et le besoin d'une réactivité en temps réel sur le lieu de travail.

C'est l'architecture dont les opérations de fabrication modernes ont réellement besoin.

L'architecture n'apporte de la valeur que si les utilisateurs s'en servent réellement. C'est là que nous constatons que de nombreux projets MES s'enlisent discrètement.

Le système est mis en place, les données circulent, puis les opérateurs trouvent des solutions de contournement, car l'interface ne correspond pas à la manière dont le travail s'effectue réellement sur le terrain.

Pour y parvenir, il faut réfléchir à ce dont chaque partie prenante a réellement besoin de la part d'une couche d'exécution.

Les opérateurs ont besoin de flux de travail numériques guidés qui s'adaptent au contexte. Si une référence change, les instructions doivent s'adapter en conséquence. Si une étape échoue à un contrôle, le système doit réorienter le processus en conséquence. Les écrans statiques qui reproduisent un formulaire papier ne permettent pas cela. Ils font peser à nouveau la charge cognitive sur l'opérateur au lieu de l'alléger, ce qui est précisément le problème que la plupart des fabricants tentent de résoudre.

Les ingénieurs de processus doivent pouvoir mettre à jour la logique des flux de travail sans devoir attendre qu'une file d'attente de développement se libère. Lorsqu'un processus change, qu'un écart est consigné ou qu'une nouvelle variante de produit est introduite, les personnes les plus proches de ce travail doivent pouvoir réagir rapidement. Les longs cycles de développement sur mesure rompent cette boucle de rétroaction et entraînent Amélioration continue d'une habitude quotidienne à un événement trimestriel.

Les responsables ont besoin d'une visibilité qui reflète ce qui se passe réellement au niveau de l'exécution, et non pas simplement des données brutes de télémétrie des machines regroupées dans un Tableau de bord distinct. Savoir qu'une machine est en marche n'apporte pas autant d'informations que de savoir qu'une machine est en marche, qu'un opérateur en est à l'étape 7 sur 12 et qu'un signal d'alerte qualité a été déclenché il y a 20 minutes. Une visibilité opérationnelle connectée signifie que ces signaux sont regroupés en un seul et même endroit.

Les acteurs des domaines informatique (IT) et opérationnel (OT) ont besoin d'une adaptabilité encadrée. Donner aux équipes de terrain les moyens de créer et de modifier des applications n'est viable que si cela s'appuie sur une structure de gouvernance. Des processus d'approbation configurables, des contrôles des changements et des autorisations d'accès permettent d'éviter qu'une flexibilité bien intentionnée ne se transforme en prolifération d'applications et en casse-tête pour les audits.

Le modèle qui permet de concilier tout cela repose sur une démarche d'amélioration pilotée par le terrain et encadrée par les technologies de l'information. Ce sont les opérateurs et les ingénieurs qui sont à l'origine des changements. Les services informatiques et opérationnels définissent les limites à respecter. C'est cet équilibre qui empêche l'autonomisation de se transformer en un risque de non-conformité et le contrôle de devenir un frein.

L'argument architectural n'est valable que s'il trouve un écho dans la réalité de la mise en œuvre. Voici comment la couche périphériqueTulip fonctionne concrètement sur le terrain.

Connecter des machines sans programme d'intégration complexe. Tulip Appareils Edge connecte les machines, les capteurs et les outils intelligents directement aux applications et fait office de source native de données machine. Vous n'avez pas à attendre la mise en place d'un projet de middleware sur mesure pour intégrer les données de signal dans un flux de travail. La connexion fait partie intégrante de l'environnement de développement d'applications ; il ne s'agit pas d'une initiative informatique distincte suivant un calendrier différent.

La connectivité des installations existantes est une véritable option, et non une solution de fortune. La plupart des usines ne partent pas de zéro. Tulip les environnements mixtes grâce à Node-RED sur Appareils Edge, aux modèles de connecteurs-hôtes locaux, ainsi qu’aux configurations orientées OPC UA (architecture unifiée de communication en plateforme ouverte) MQTT. Cette combinaison vous permet d’accéder aux équipements existants, aux automates programmables (PLC) et aux systèmes locaux sans avoir à reconstruire votre infrastructure au préalable. Elle réduit l’ampleur des besoins réels en matière de connectivité.

Des conseils à l'opérateur intégrés à l'exécution. Les instructions de travail numériques dans Tulip des documents statiques affichés à l'écran. Il s'agit de flux de travail dynamiques qui réagissent aux signaux de la machine, déclenchent des étapes en fonction d'événements en temps réel et enregistrent les données contextuelles au moment même où le travail est effectué. Lorsqu'un outil dynamométrique signale la fin d'une opération, l'application réagit. Lorsqu'une étape est ignorée ou qu'une valeur sort de la plage autorisée, le système le détecte. C'est là toute la différence entre un document de référence et une couche d'exécution.

La vision industrielle boucle la boucle au niveau du poste de travail. Tulip utilise des caméras standard exécutant des tâches en périphérie locale pour assister les opérateurs grâce à des contrôles visuels pratiques : reconnaissance optique de caractères (OCR) pour la vérification des étiquettes et des pièces, détection des anomalies, détection des gabarits, Pick to Light et inspection des défauts. Il ne s'agit pas d'un système de vision distinct ajouté en périphérie. Il fonctionne au sein du même environnement applicatif, ce qui signifie que le résultat du contrôle visuel peut déclencher l'étape suivante du flux de travail, signaler un événement lié à la qualité ou arrêter un processus avant qu'un défaut ne passe en aval.

Commencez par cibler vos efforts, puis développez-vous de manière réfléchie. Le modèle composable Tulip s'articule autour d'un modèle de données commun et de composants réutilisables. Une équipe peut déployer un projet pilote ciblé sur une ligne ou un processus, en valider la valeur, puis étendre le projet à partir de là. Vous ne vous engagez pas d'emblée à remplacer l'intégralité de votre plateforme. L'architecture est conçue pour permettre un déploiement par étapes, ce qui est essentiel lorsque vous devez gérer des contraintes de ressources, Gestion du changement et le risque opérationnel lié à l'intervention sur un environnement de production en service.

Accélération du délai avant la première valeur

Avec un MES monolithique, le délai entre la signature du contrat et la mise en service du logiciel sur le terrain se compte souvent en trimestres. composable natives de l'environnement de production réduisent considérablement ce délai.

Apps être développées et déployées en quelques jours. Les premiers résultats, qu'il s'agisse d'instructions de travail guidées, d'un formulaire de saisie des données qualité ou d'un outil de suivi des temps d'arrêt des machines, sont visibles en quelques semaines. Les déploiements à plus grande échelle s'effectuent en quelques mois plutôt qu'en plusieurs années.

Cette rapidité est essentielle, car les problèmes de production ne peuvent pas attendre la fin de longs cycles de déploiement pour être résolus.

Une visibilité en temps réel dans son contexte opérationnel

Les données brutes de télémétrie vous indiquent ce que fait une machine. Elles ne vous indiquent pas ce que faisait l'opérateur au même moment, quelle étape du processus était en cours, ni si un incident lié à la qualité a été enregistré deux minutes plus tôt.

Les plateformes natives en périphérie relient ces signaux entre eux : l'exécution des workflows, les données machine, les événements liés à la qualité et les actions des opérateurs sont enregistrés en relation les uns avec les autres. C'est ce contexte qui permet de tirer parti de cette visibilité, au lieu de la considérer comme une simple source d'informations.

Une connectivité simplifiée pour les sites désaffectés

La plupart des usines ne sont pas des installations entièrement nouvelles. Elles utilisent un mélange d'équipements datant de différentes époques, provenant de différents fournisseurs et fonctionnant avec différents protocoles de communication.

La mise MES d'un MES traditionnel avec cet environnement devient généralement un projet à part entière, nécessitant des travaux d'intégration sur mesure qui alourdissent les délais et les coûts avant même que vous n'ayez saisi la moindre donnée.

La connectivité native au niveau des périphériques, grâce à la prise en charge des modèles de connecteurs locaux, à Node-RED et aux configurations basées sur OPC UA (architecture unifiée de communication en plateforme ouverte) MQTT, permet de moderniser ces environnements mixtes sans devoir procéder au préalable à une refonte complète de l'infrastructure.

Amélioration continue pilotée par les équipes de terrain

L'un des coûts cachés des MES monolithiques MES le temps nécessaire pour apporter la moindre modification. Qu'il s'agisse d'un ingénieur de procédés qui identifie une meilleure séquence, d'un superviseur qui doit ajouter un contrôle qualité ou d'un chef d'équipe qui souhaite adapter une consigne de travail : dans un système traditionnel, ces modifications nécessitent souvent l'ouverture d'un ticket de développement, un cycle de contrôle des modifications et des semaines d'attente.

Composable permettent aux responsables de processus d'apporter ces modifications directement, tout en préservant les contrôles de gouvernance, les procédures d'approbation et la gestion des versions. Le cycle d'amélioration suit le rythme de l'activité, et non celui de l'éditeur de logiciels.

Réduction des coûts de coordination à long terme

Tout changement nécessitant l'intervention d'un prestataire entraîne des coûts supplémentaires et des retards. Au fil du temps, cela se traduit par une charge opérationnelle considérable, que les directeurs des opérations ressentent particulièrement lorsqu'ils tentent de justifier le coût total de possession d'un système qui nécessite encore l'aide d'un prestataire externe pour mettre à jour un champ de formulaire.

Composable réduit le nombre de changements nécessitant ce type de coordination. Les équipes gèrent davantage de tâches en interne, le recours aux prestataires est réservé aux tâches véritablement complexes, ce qui modifie d'autant la structure des coûts à long terme.

Le choix d'une plateforme opérationnelle est plus facile lorsque l'on sait quelles questions poser. Voici quelques éléments à prendre en compte la prochaine fois que vous évaluerez des solutions.

En combien de temps peut-elle connecter des machines, des appareils et des systèmes locaux ?
Si la connexion d'une machine CNC ou d'une caméra de vision nécessite un programme d'intégration dédié, vous avez affaire à un modèle obsolète. Une architecture moderne doit prendre en charge la connectivité des installations existantes via des protocoles standard tels que OPC UA (architecture unifiée de communication en plateforme ouverte) le MQTT, avec Appareils Edge servir de sources de données natives dès leur mise en service. L'objectif est d'obtenir des données connectées en quelques semaines, et non en plusieurs trimestres.

Les équipes de terrain peuvent-elles modifier les flux de travail sans l'intervention d'un spécialiste ?
Les ingénieurs des procédés et les responsables de ligne savent reconnaître lorsqu'une instruction de travail est erronée ou qu'une étape manque. Si chaque correction nécessite l'ouverture d'un ticket auprès du service informatique ou le recours aux services d'un fournisseur, vos cycles d'amélioration seront toujours en retard sur vos opérations. Recherchez des plateformes sur lesquelles les responsables des processus peuvent mettre à jour la logique dans un cadre réglementé, avec des procédures de validation et un contrôle des versions intégrés, et non ajoutés a posteriori.

Ces données issues des machines et des capteurs sont-elles transformées en instructions destinées à l'opérateur sur le lieu de travail ?
Les données brutes qui restent dans un Tableau de bord consulte n'ont aucune valeur opérationnelle. La question la plus pertinente est de savoir si le système est capable de prendre un signal provenant d'une machine, une mesure d'un capteur ou le résultat d'un contrôle visuel, et de le présenter à l'opérateur sous forme d'invite, d'étape de validation ou d'alerte qualité au moment où cela compte vraiment.

L'architecture prend-elle en charge un déploiement par étapes et une expansion progressive ?
Les déploiements « big bang » comportent des risques réels. Vérifiez si la plateforme permet de commencer par une seule ligne ou un seul processus, en s'appuyant sur un modèle de données commun, puis de s'étendre de manière réfléchie. Composable vous permettent de démontrer rapidement la valeur ajoutée et de faire évoluer ce qui fonctionne.

Peut-elle coexister avec vos MES existants ERP, PLM, SGQ (système de gestion de la qualité) ou MES ?
Un remplacement est rarement envisageable dans un délai court. La plateforme que vous choisirez devra s'intégrer aux systèmes qui gèrent déjà votre entreprise, sans entrer en concurrence avec eux pour les mêmes données ni vous obliger à démanteler votre infrastructure avant d'en tirer le moindre bénéfice.

La question de l'architecture ne se résume pas à opposer le cloud à la périphérie. Il s'agit plutôt de déterminer où chaque couche est la plus efficace.

Le cloud prend en charge ce pour quoi il est le plus performant : la coordination entre les sites, l'analyse à grande échelle, la gouvernance, la gestion de la conformité et les intégrations qui relient les opérations aux systèmes ERP, PLM et de gestion de la qualité. C'est ainsi que vous bénéficiez d'une visibilité sur l'ensemble d'un réseau distribué et de l'infrastructure nécessaire pour gérer le changement de manière cohérente.

Edge prend en charge ce que le cloud ne peut pas faire en temps réel : l'exécution locale, Connectivité machine, l'assistance à l'opérateur sur le poste de travail, ainsi qu'une réactivité qui ne dépend ni de la latence du réseau ni d'un aller-retour vers un serveur distant. C'est là que le travail s'effectue réellement, et c'est là que la plupart des systèmes traditionnels ont toujours échoué.

Ce sont les applications de terrain qui relient ces deux niveaux aux personnes qui effectuent le travail.

Lorsque les opérateurs disposent de flux de travail guidés qui reflètent la logique actuelle des processus, et lorsque les ingénieurs de procédés peuvent mettre à jour ces flux sans devoir attendre qu'une file d'attente de développement se libère, Amélioration continue une démarche à laquelle le personnel de terrain participe réellement, plutôt qu'une initiative imposée par la hiérarchie. La gouvernance reste en place. Les équipes IT/OT continuent de contrôler les garde-fous. Mais les personnes les plus proches des processus disposent des outils nécessaires pour agir en fonction de ce qu'elles constatent.

composable Tulip s'articule autour de cette structure à trois niveaux. Les fabricants peuvent commencer par un déploiement ciblé, démontrer la valeur ajoutée en quelques semaines, puis étendre progressivement leur déploiement à l'ensemble des gammes de produits, des sites et des domaines de processus. Il s'agit là d'une alternative intéressante au cycle complet MES , qui nécessite souvent plus de temps et d'argent que ne le justifient les gains opérationnels obtenus.