API

API & SECURITE – Du SI au RSSI

API & SECURITE - Du SI au RSSI

29 octobre 2024

Architecture

Thomas Jardinet

Manager Architecture

Cet article a eu en primo-inspiration mon sentiment qu’IT et Cyber travaillent malheureusement de manière trop souvent silotées. Avec des contraintes de sécurité souvent mal abordées ou insuffisamment partagées. Inspiration également au travers de rencontres de personnes travaillant dans le Cyber, qui peut-être se reconnaîtront. 

En effet, la sécurité des API, côté IT, est souvent perçue comme un sujet couvert à partir du moment ou l’on gère bien l’authentification, les droits, et qu’on utilise une API Gateway. Oui bien sûr cela est nécessaire. Mais penser sécurité des API, au regard de ce que ce sujet implique, c’est penser un gros pan de la sécurité de son SI.

Ne venant pas du monde du Cyber, cet article n’aura comme seule prétention d’essayer de se faire rencontrer ces deux mondes. En abordant tous les aspects que la sécurité des API peut couvrir. Et évidemment, cet article est une invitation à vous rapprocher de vos équipes Cyber ! Et de vous fournir une liste de courses aussi synthétique que possible pour échanger entre équipes IT et Cyber. Mais un peu longue quand même. D’où le formalisme très concis choisi pour cet article.

Pour se faire, nous allons dans un premier temps expliciter les risques que nous identifions, pour ensuite aborder la sécurisation des API sur toute leur chaîne de valeur, du DevSecOps aux WAF d’API (WAAP pour Web Application and API Protection). Pour ensuite offrir un panorama de technologies, et enfin finir avec des préconisations. Sur ce, on y va !

Pourquoi la sécurité des API est-elle cruciale ?

  1. Les données exposées sont très souvent sensibles : Les API renvoient souvent des données confidentielles, rendant leur protection indispensable.
  2. C’est un vecteur d’attaque privilégié : En tant que point d’entrée unique des données,  les APIs sont des points d’attaque de choix.
  3. Leur complexité est croissante : L’évolution des architectures (microservices, coud, service mesh, …) peut augmenter la surface d’attaque potentielle.
  4. Les API doivent respecter le cadre réglementaire : RGPD, PCI DSS, PSD2, etc…, autant de réglementations qui exigent une exposition sécurisée des API.

Cela n’arrive qu’aux autres? Et bien non. 

2019. Facebook. Fuite de données concernant 540 millions d’utilisateurs à cause de serveurs non sécurisés et accessibles via des API.

2018. Twitter. Une mauvaise gestion des autorisations d’accès a rendu disponibles les messages privés de certains utilisateurs.

Maintenant que ces enjeux sont rappelés, nous allons détailler les risques et solutions.

API
Source : StartUp Stock Photo, Pexels

I. Les risques majeurs liés à la sécurité des API

1.1 Vulnérabilités courantes des API

1.1.1 Injection de code

L’injection de code est l’une des menaces les plus connues, avec 

Mais aussi par commandes avec l’exemple pas si ancien de la faille Log4J.

1.1.2 Authentification et autorisation inadéquates

Il est primordial d’avoir une politique d’authentification et d’autorisation bien appliquée afin de bloquer au mieux les attaquants. On peut retenir comme principes : 

1.1.3 Exposition de données sensibles

Les API peuvent involontairement exposer des données sensibles et inutiles si elles ne sont pas correctement définies, configurées ou sécurisées. Les cas typiques sont  :

Les erreurs sont mal gérées : Messages d’erreur révélant des informations sensibles sur l’infrastructure.

1.2 Menaces émergentes et sophistiquées

1.2.1 Attaques par force brute et credential stuffing

Stratégie largement connue, consistant à tester des combinaisons de noms d’utilisateur et de mots de passe. Elles sont aussi simples à parer que particulièrement dangereuses car :

1.2.2 Attaques « Man-in-the-Middle » (MITM)

Une attaque MITM consiste à ce que l’attaquant se place entre le client et l’API Gateway pour intercepter ou modifier les échanges. Les risques incluent :

1.2.3 Attaques DDoS

Ces attaques consistent à avoir un très grand nombre d’appels, afin de rendre indisponible l’API. Elles peuvent prendre plusieurs formes :

1.3 Risques spécifiques aux architectures modernes

1.3.1 Microservices et conteneurisation

La conteneurisation et les microservices ajoutent de nouveaux défis de sécurité :

L’exposition accrue des API internes : Les API internes ne doivent absolument pas être exposées en externe !

1.3.2 API dans le cloud

Le déploiement d’API dans des environnements cloud présente des risques spécifiques :

1.3.3 Shadow API et API zombies

Les « shadow API » (non documentées ou non gérées) et les « API zombies » (obsolètes mais toujours actives) représentent des risques significatifs :

Les Accès non contrôlés : Il ya alors un risque d’exploitation par des attaquants sur des systèmes ou des données sensibles.

II. Stratégies et solutions pour sécuriser efficacement les API

2.1 Approche globale de la sécurité des API

2.1.1 Sécurisation de l’API via DevSecOps

L’approche DevSecOps permet de sécuriser une API en amont de son déploiement, via :

La gestion continue des vulnérabilités : Code, librairies, dépendances, etc… Tous ces éléments peuvent faillir ou contenir des failles découvertes après coup. Il faut donc les détecter et les corriger.

2.1.2 Gouvernance et politiques de sécurité des API

Que serait-on sans gouvernance ? C’est évidemment un point primordial, sur lequel on sera particulièrement vigilant sur les aspects suivants  :

Des audits réguliers : Afin d’évaluer de manière continue la conformité des API aux politiques de sécurité.

2.1.3 Formation et sensibilisation des équipes

La sécurité des API repose en grande partie sur les compétences et la vigilance de toutes les équipes, qu’elles soient devops, cyber ou dev :

Une culture de la sécurité : En encourageant à signaler et à résoudre les problèmes de sécurité.

2.2 Technologies et outils de sécurisation des API

2.2.1 API Gateways et Web Application and API Protection (WAAP)

Les API Gateways (et leurs cousins service mesh et micro-gateway) et les WAAP (WAF pour API, si vous préférez) représentent la première ligne de défense :

Et en analysant le trafic : En détectant et en bloquant les comportements suspects.

2.2.2 Solutions de gestion et de protection des API

D’autres outils spécialisés existent, qui ont des fonctionnalités avancées pour la sécurité des API :

Solutions de conformité réglementaire : Afin de démontrer la conformité aux règlements de sécurité.

2.2.3 Outils d’analyse de la sécurité des API

Des outils dédiées existent également pour déterminer des failles spécifiques aux API :

Outils d’analyse statique et dynamique : Il existe des SAST et DAST adaptés aux API.

2.3 Meilleures pratiques de sécurisation des API

2.3.1 Authentification et autorisation robustes

2.3.2 Centralisation et découpage des API Gateway

Une API Gateway est à placer idéalement de manière centrale dans son architecture pour ne pas multiplier les points d’entrée. On peut néanmoins avoir deux API Gateway, une “publique” et une autre “privée” afin de mitiger les risques au mieux :

2.3.3 Chiffrement et protection des données

2.3.4 Gestion des logs et audit

2.3.5 Surveillance en temps réel

2.3.6 Tests de pénétration et validation de la sécurité

Conclusion

Comme on peut le voir, la sécurité des API demandent des compétences dans diverses équipes, mais également un engagement de tous. Des solutions informatiques existent, mais elles ne sont rien sans une politique de sécurité partagée à tous et pour tous. Et aussi et surtout l’établissement des bonnes pratiques définies en interne, comme nous l’avons partagées dans cet article. 

Pour aller plus loin, on pourra aussi se reporter au RGS de l’ANSSI (https://cyber.gouv.fr/le-referentiel-general-de-securite-rgs), mais aussi faire de la veille sur les outils de découvertes d’API, l’utilisation de l’IA pour la sécurité, et bien sur aller faire un tour sur l’OWASP API Security Project (https://owasp.org/www-project-api-security/)

Devops, Dev, RSSI, c’est à vous !

data lakehouse

DATA Lakehouse – Exploration d’une Architecture de plateforme de données innovante

DATA Lakehouse - Exploration d'une Architecture de plateforme de données innovante

22 octobre 2024

Architecture

Mohammed Bouchta

Consultant Senior Architecture

Après avoir introduit les concepts fondamentaux d’un lakehouse dans notre précédent article, plongeons maintenant dans les détails qui font du lakehouse une solution d’architecture alignée sur les principes d’une modern data plateform.

Nous allons explorer son fonctionnement interne et les technologies clés qui le soutiennent.

data lakehouse
Source : Pexels – Tima Miroshnichenko

Fonctionnement d’un Lakehouse

L’architecture lakehouse représente une évolution significative dans le traitement et la gestion des données, cherchant à harmoniser les capacités de stockage d’un datalake avec les fonctionnalités analytiques et transactionnelles avancées d’un data warehouse. Cette convergence vise à créer une plateforme flexible, capable de gérer à la fois l’analyse de données historiques et les opérations transactionnelles, sans faire de compromis sur la performance, la sécurité, ou la qualité des données.

Rôle des métadonnées

Au cœur de cette innovation, l’usage stratégique des métadonnées joue un rôle prépondérant, orchestrant avec la gestion des schémas de données et leur évolution.

Les métadonnées, dans l’écosystème lakehouse, ne se limitent pas à la gouvernance et à la qualité des données, bien que ces aspects soient importants, notamment pour soutenir des transactions fiables. Elles permettent également d’indexer de manière efficiente les données susceptibles d’être requises, facilitant ainsi leur accès et leur analyse. 

Cette architecture assure que, même au sein d’un stockage de données bruts et diversifiées, l’information pertinente peut être rapidement localisée et exploitée.

Système de stockage 

Le lakehouse exploite les avantages économiques du stockage en DataLake, tel que le système de fichiers distribués HDFS ou les solutions de stockage objet dans le cloud, comme Amazon S3 et Azure Blob Storage. Ces plateformes de stockage, reconnues pour leur coût-efficacité, en grande partie grâce à la séparation du stockage et du calcul, sont complétées par une couche sémantique riche, pilotée par les métadonnées. Cette couche ne se contente pas de cataloguer les données; elle améliore aussi leur traitement et facilite leur accès, optimisant de ce fait l’efficacité générale de la plateforme.

Gestion transactionnelle des données

La fusion réussie de ces éléments au sein d’une architecture lakehouse repose sur l’intégration de principes transactionnels rigoureux, tels que l’atomicité, la cohérence, l’isolation, et la durabilité (ACID). Ces principes sont essentiels pour garantir la fiabilité et l’intégrité des données, permettant de s’appuyer sur le lakehouse pour des opérations critiques sans craindre de compromettre la qualité ou la sécurité des informations traitées.

Meilleure performance qu’un Datalake

Par ailleurs, pour ce qui est de l’amélioration des performances, le lakehouse intègre des mécanismes de mise en cache avancés. Ces systèmes sont conçus pour précharger en mémoire les données les plus sollicitées, accélérant ainsi significativement le temps d’accès et la réactivité de la plateforme.

Technologies Clés

La réalisation d’un lakehouse repose sur des technologies avancées qui permettent de surmonter les défis traditionnels posés par les datalakes et les data warehouses offrant une flexibilité, une fiabilité et des performances accrues pour la gestion et l’analyse des données à grande échelle.

Voici un aperçu de ces technologies clés :

Delta Lake

Delta Lake est une couche de stockage open source conçue pour apporter la gestion transactionnelle ACID aux datalakes. Cette technologie transforme un datalake en un système capable de gérer des opérations de lecture et d’écriture concurrentes, garantissant ainsi l’intégrité des données. Avec Delta Lake, les utilisateurs peuvent effectuer des mises à jour, des suppressions, des insertions, et même des merges (fusion de données) directement sur les données stockées dans un datalake, tout en maintenant un historique complet des modifications. Cela permet une gestion des données plus flexible et robuste, facilitant des cas d’utilisation comme le rollback pour corriger des erreurs ou auditer des modifications. De plus, Delta Lake optimise les requêtes en utilisant le « data skipping » (saut de données non pertinentes), améliorant ainsi la vitesse d’analyse des vastes ensembles de données.

Apache Hudi

Apache Hudi (Hadoop Upserts Deletes and Incrementals) est une autre technologie open source qui révolutionne la gestion des données dans les datalakes. Elle permet des mises à jour et des suppressions rapides, ainsi que des insertions et des requêtes incrémentielles sur de grands ensembles de données. Apache Hudi introduit le concept de « views » (vues) de données, permettant aux utilisateurs de voir des snapshots des données à un moment choisi ou des changements sur une période, rendant ainsi possible la gestion de versions et le time travel (navigation temporelle dans les données). Cette capacité à gérer des modifications de données de manière efficace rend Hudi particulièrement adapté aux environnements où les données changent fréquemment, supportant des cas d’utilisation tels que la capture de données modifiées (Change Data Capture, CDC) et les pipelines de données en temps réel.

Apache Iceberg

Apache Iceberg est un format de table open source qui vise à améliorer la gestion et les performances des requêtes dans les datalakes. 

Iceberg traite de nombreux problèmes rencontrés avec les formats de fichiers traditionnels et les modèles de métadonnées dans les datalakes, tels que la complexité de gestion des schémas évoluant dans le temps ou les problèmes de performance des requêtes sur de grandes tables. 

Avec Iceberg, les tables sont traitées comme des entités de première classe, supportant des fonctionnalités avancées telles que les schémas évolutifs, les partitions cachées, et les transactions atomiques. 

Le format est conçu pour être agnostique au moteur de calcul, permettant ainsi son utilisation avec diverses plateformes d’analyse de données, telles que Spark, Trino et Flink. 

Iceberg optimise également les performances des requêtes en utilisant un indexation fine des données, ce qui réduit le volume de données scannées lors des analyses.

Conclusion

En conclusion, le lakehouse émerge comme une solution hautement performante et flexible qui étend la portée et les capacités d’un datalake en combinant le stockage économique des datalakes avec les capacités d’analyse et de gestion transactionnelle des data warehouses, tout en exploitant intelligemment les métadonnées pour la gouvernance, l’indexation, et l’optimisation des accès sans pour autant éclipser le rôle stratégique que peut jouer un datahub dans l’écosystème global de gestion des données au sein du système d’information.

data lakehouse

Data Lakehouse – Introductions des concepts

22 octobre 2024

Julien Catelain

Consultant Senior Architecture

Datalake, Datawarehouse, Datalakehouse… Le métier de la donnée a le don pour créer des noms assez simples à associer au sujet, mais qui peuvent rapidement devenir confusants.
Ce billet vise à vulgariser ces 3 concepts, afin de vous permettre de tenir le fil de la discussion lors de vos discussions avec les experts data.

data lakehouse

Les patterns historiques

Le Datawarehouse (entrepôt de données) est un pattern de base de données décisionnelles, datant de la fin des années 80 : il agrège des données sélectionnées, mises en qualité, structurées, et historisées afin de permettre de les exploiter dans le cadre de cas d’usage « décisionnels ».
Ces données ne sont pas altérables, ce qui garantit qu’un même traitement donnera le même résultat peu importe le nombre de fois et le moment où il sera réalisé.
Ce cadre de stockage permet de faire croiser des données issues de systèmes applicatifs distincts, afin de « casser » les silos de données, et permettre une vision transversale de l’entreprise, tout en permettant de comparer différentes périodes.
L’inconvénient du Datawarehouse est principalement son coût de stockage élevé, du fait de toutes les étapes de « travail » autour de la donnée.

Le Datalake (lac de données) s’est construit afin de répondre aux faiblesses du Datawarehouse : c’ est un espace de stockage, agrégeant des données (non structurées, semi structurées et structurées), sous leur forme brute (pas de traitement de normalisation / mise en qualité à l’ingestion).
L’objectif de cette brique applicative est de proposer un stockage à bas coûts, permettant de mettre à disposition un vaste volume de données, de manière agnostique au regard de leur exploitation future.
Ce volume de données permet de nourrir différents types de cas d’usage : alimentation de bases de données spécialisées (par exemple décisionnelles, comme un Datawarehouse), ou exploitation dans le cadre de traitements nécessitant un volume important de données mise à disposition (Data Science, Machine Learning, Intelligence Artificielle…).
Il n’a cependant pas ambition à agréger toutes les données de l’entreprise, ou de les stocker n’importe comment, et c’est justement un problème qui a tendance à se développer avec le temps, en l’absence d’un cadre définissant la gouvernance des données, et la politique de rétention de ces dernières.
Et là, le Datalake devient le Dataswamp…ce qui rend  l’exploitation des données compliquée voir impossible, tout en faisant augmenter les coûts…

Le nouveau venu

Le Data Lakehouse (maison lac… ne cherchez pas de traduction littérale !) est une hybridation de ces 2 composants applicatifs, visant à proposer le meilleur des deux mondes, tout en couvrant l’ensemble des cas d’usages sus mentionnés.
Comme le Datalake, il permet d’agréger différents types de données (structurées, semi structurées ou non structurées). Cependant, grâce à l’exploitation d’une couche de métadonnées permettant de faire le lien avec les différentes données agrégées, les transactions ACID (atomicité, cohérence, isolation et durabilité) deviennent possibles.
De même, l’ingestion de données en temps réel (streaming) devient possible, ce qui permet de répondre à de nouveaux cas d’usage (pilotage à chaud, exploitation des données IoT).
C’est un pattern permettant de conserver un stockage à moindre coût propre au Datalake, ainsi que la capacité d’analyse d’un Datawarehouse.

 Dans un second article, nous allons faire un focus sur le Data Lakehouse, en soulevant le capot afin de mieux comprendre son fonctionnement.

Le Visual Programming part à la conquête des DSI

Le Visual Programming part à la conquête des DSI

22 octobre 2024

Architecture

Clément Lefranc

Senior Manager Architecture

Le NoCode Summit 2024 en a été la vitrine et s’est révélé fort intéressant par bien des aspects :

Si vous parlez de NoCode/LowCode…un vaccin des dernières tendances vous sera bénéfique.

NoCode, démarrant par une négation, n’est pas vendeur, braque les développeurs avec pour conséquence un frein à l’adoption de ces technologies…Alors même que le “NoCoderequiert des compétences fondamentales telles que la logique et l’algorithmie. Le “LowCode” quant à lui requiert parfois de coder concrètement pour couvrir le cas d’application souhaité.

Désormais, il conviendra de parler de :

Il s’agissait ici de la troisième édition du Summit, et une belle montée en maturité (Prod ready) des acteurs a été constatée, ne serait-ce que de part leur adoption par des Grands Comptes (ex : BRED, System U, BNPP, Docaposte, CDC, Europ Assistance, LCL, L’Oréal, BPI France) qui témoignent de retours d’expériences très positifs.

Vous constaterez sur les affichages de sponsoring du foisonnement de solutions. Nous assisterons avec quasi certitude à une consolidation de marché dans les années à venir car plusieurs solutions se concurrencent sur les mêmes positionnements, avec bien évidemment des particularités.

Voici un aperçu des différents positionnements constatés :

dsi
Source : Kevin Ku – Pexels

Le choix de l’une ou l’autre des solutions doit se faire de façon éclairée avec une liste de critères / contraintes bien établie, dont voici un petit extrait :

Des stacks commencent d’ores et déjà à se démarquer via les témoignages :

Se lancer dans l’aventure Visual Programming, c’est être conscient des problèmes que vous rencontrez et des bénéfices qu’ils peuvent vous apporter :

Le NoCode ne rime pas avec NoMethodology. Qu’il s’agisse d’une démarche tactique ou stratégique, il y a des clés de succès :

Toute rupture technologique, tout nouvel écosystème apporte avec lui son lot de freins et de réticences:

Actuellement, moins d’un pourcent de la population mondiale sait programmer. La démocratisation et l’accessibilité introduite par le Visual Programming a le bénéfice d’ouvrir la voie à toute une Diversité de personnes en quête de reconversion.

Mais … comme le souligne très justement Jean-Marc Jancovici également le net inconvénient et le risque majeur d’accentuer significativement une prolifération applicative avec des services digitaux futiles et inutiles. Sur notre planète à ressource finie, le numérique représente 4% des gaz à effet de serre (GES), cette débauche de moyens (énergétiques et intellectuels) sur ces sujets ne fait qu’accroître exponentiellement les usages digitaux… et leurs impacts.

Derrière mon clavier, je visual programme avec modération et sobriété. La consommation digitale excessive est dangereuse pour la planète, ceci est un message de Rhapsodies Conseil.

rpa

Le RPA Raisonné : Adoptez le robot qu’il vous faut !

Le RPA Raisonné : Adoptez le robot qu’il vous faut !

11 septembre 2024

Salomé Culis

Consultante Architecture

A la recherche d’un moyen pour automatiser vos processus, vous trouvez enfin la solution ! Des paillettes plein les yeux, vous découvrez le RPA et ses bienfaits. 

Chez Rhapsodies Conseil, nous aimerions vous proposer une vision raisonnée du RPA. 

Pour cela, nous vous proposons d’explorer les points suivants : 

Les attraits du RPA

Le RPA (Robotic Process Automation) paraît attrayant par rapport à d’autres solutions d’automatisation. 

Sur le papier, ça a l’air parfait pour vous ! 

Désolée de vous décevoir mais le RPA n’est pas une solution miracle. 

Commençons par le début : qu’est-ce que le RPA ?

Revenons aux basiques : le RPA c’est quoi ?

Le RPA est un logiciel d’automatisation des processus métiers (ou IT d’ailleurs). Les scripts reproduisent l’interaction d’un humain avec les IHM des applications. 

Le RPA est utilisé sur des processus stables basés sur des données structurées. Et dont le volume est important. 

L’idée était de débarrasser les utilisateurs des tâches répétitives et à faible valeur ajoutée. Fini les tâches où nous reproduisons toujours les mêmes clics jusqu’à en devenir fou. Et dont la répétition favorise le risque d’erreur à la longue. 

Voici quelques exemples de cas d’usage sur lesquels le RPA peut être utilisé : 

Le RPA peut être utilisé sur tous types de processus et dans tous les secteurs d’activité. 

Vous vous demandez sûrement pourquoi il n’a pas envahi le marché tout de suite ? À cause de ses modalités d’intégration.

Vers davantage de modalités d’intégration

La première limite du RPA était évidemment la fréquence d’évolution du processus métier et des IHM. Par exemple, le bouton “valider” change de place et votre robot est bon pour la casse. 

C’est le cas avec les applications maison qui évoluent fréquemment pour répondre à la demande des métiers. Ou les applications SaaS dont la roadmap éditeur n’est pas maîtrisée. 

Le RPA a donc évolué pour dépasser cette limite. Les éditeurs se sont mis à proposer de nouvelles capacités d’intégration. 

Deux nouvelles capacités ont vu le jour : 

Ces capacités d’intégration sont bien entendu complémentaires avec l’intégration par les IHM. Elles peuvent être utilisées par le même robot. 

Cela permet d’étendre le périmètre d’intervention du RPA à de nouveaux processus. Il n’est plus limité à des processus manuels basés sur des applications dont les IHM évoluent peu.

rpa architecture

Maintenant que cette limite originelle est dépassée, qu’est-ce qui freine pour l’adopter ? Il reste nécessaire de bien choisir les cas d’usage sur lesquels appliquer du RPA.

Dans quels cas l’utilisation du RPA est-elle pertinente ?

Le RPA est particulièrement pertinent pour : 

– des applications qui sont arrivées à maturité, évoluent peu et dont l’intégration avec le Système d’Information ne pourra pas prendre en charge les automatisations souhaitées, 

– des petites migrations de données entre deux applications par exemple.

Vos premiers cas d’usage sélectionnés et priorisés, vous trépignez d’impatience !

Pas si vite, nous vous invitons d’abord à prêter attention aux points suivants. 

Comment sécuriser le lancement d’une initiative RPA ?

Nous avons relevé trois points d’attention majeurs à considérer : 

Ces points d’attention considérés, foncez sur votre premier cas d’usage ! Nous avons encore quelques conseils dans notre manche, rassurez-vous.

Les étapes indispensables lors du cadrage d’un cas d’usage

De notre point de vue d’architecte (et expert en transformation digitale), plusieurs sujets sont à étudier : 

Voilà, vous savez tout ! Le RPA est une solution d’automatisation frugale des processus. Vous l’avez compris, c’est une solution et non une fin en soi. 

Cette solution est adaptée si l’entreprise ne dispose pas de plateformes d’intermédiation industrielles. Et qu’il n’y a pas d’autres possibilités d’automatisation au vu des applications concernées. Comme nous l’avons vu, les cas d’usage doivent être rigoureusement sélectionnés et priorisés.

Avant de filer, nous avons un dernier sujet à explorer. L’IA qui révolutionne le marché de l’IT, ne peut-elle pas aider le RPA ? Si, bien sûr, et nous allons voir comment.

Quelles perspectives pour le futur ?

Le RPA bénéficie des apports de l’IA. Il peut interagir avec d’autres technologies, par exemple : 

On parle dans ce cas d’hyper automatisation. La promesse est la suivante : automatiser des processus moins structurés que ceux concernés par le RPA “classique”. 

Cet ensemble de solutions propose des fonctionnalités intéressantes. Cela va permettre d’étendre le périmètre d’intervention du RPA. 

D’après le Gartner, d’ici 2025, 90% des éditeurs de RPA proposeront de l’automatisation assistée par de l’IA générative. 

En revanche, la mise en place d’une plateforme d’hyper automatisation va clairement au-delà d’un projet classique de RPA. A la fois en termes de coûts et de compétences.

Vous commencez à nous connaître, nous vous conseillons d’en faire une utilisation… Raisonnée.

architecture-reference

Au-delà du SI de Gestion : tour d’horizon des composants d’une plateforme SI Industrielle !

Au-delà du SI de Gestion : tour d’horizon des composants d’une plateforme SI Industrielle !

5 août 2024

– 6 minutes

Bambo Adama C.

Consultant Senior Architecture

De quoi parle-t-on ?

L’émergence des systèmes SCADA (Supervisory Control and Data Acquisition) dans les années 1980 et l’avènement de l’internet des objets (capteurs et dispositifs connectés) ont été un tournant majeur dans la tendance technologique de l’informatique industrielle. Force est de constater qu’aujourd’hui, l’informatique industrielle représente un vecteur incontournable pour transformer et moderniser l’exploitation et la maintenance des systèmes industriels. 

Pour autant, de nombreuses entreprises se heurtent à des défis majeurs liés à la fragmentation de leur systèmes d’information industriels, la plupart pour des raisons historiques. 

Dans ce contexte de fragmentation, un impact majeur est la difficulté à obtenir une vue d’ensemble cohérente des opérations industrielles ; ce qui entraîne une duplication des efforts d’exploitation et de maintenance.

Partant de ce constat, il devient dès lors intéressant de proposer une perspective visant à soutenir et à faciliter la vision d’ensemble à travers la mise en place d’une plateforme unifiée : la plateforme SI industrielle

Dans cet article, nous vous proposons de présenter les enjeux ainsi que les composants fondamentaux qui soutiennent une plateforme SI industrielle.

Proposition de définition

Une plateforme SI industrielle est un ensemble intégré de capacités technologiques et de moyens matériels fournissant un écosystème pour l’exploitation et la maintenance des systèmes industriels (usine, installations de fabrication, lignes de production, etc.). 

Quels sont les enjeux pour une entreprise de mettre en place une plateforme si industrielle ?

l’entreprise car elle nécessite des changements à plusieurs niveaux :   

Quels avantages tire-t-on de la mise en place d’une plateforme si industrielle ?

Une entreprise dotée d’une plateforme SI industrielle pour le pilotage de ses opérations industrielles peut tirer profit des avantages suivant : 

Les composants de l’architecture de référence d’une plateforme si industrielle 

Schéma : composants de base de l’architecture d’une plateforme SI industrielle

1- LES CAPACITÉS SCADA

La visualisation en temps réel de données en provenance des systèmes industriels revêt d’une importance cruciale pour une plateforme SI industrielle. Le rôle de cette capacité est de : 

L’hypervision est le niveau supérieur de surveillance et de gestion englobant l’ensemble de l’environnement industriel au travers d’une interface graphique centralisée. Cette capacité a pour objectif de :

Il s’agit de la capacité permettant la gestion et le pilotage à distance d’un système industriel (exemple : arrêt à distance d’une écluse sur une voie d’eau navigable). 

Cette capacité permet de contrôler les équipements industriels avec la possibilité pour les opérateurs d’activer ou de désactiver les paramètres des équipements à distance ; ce qui offre une flexibilité dans la gestion des opérations industrielles

2- LES CAPACITÉS VMS

Les capacités VMS (Video Management System) se réfèrent à l’ensemble des fonctionnalités offertes par les systèmes de gestion vidéo et audio. L’objectif est de permettre la gestion, l’analyse et le stockage des flux de données vidéo provenant de multiples dispositifs. 

Elle a pour rôle d’assurer la communication et l’échange de données entre les différents systèmes et l’environnement industriel. Les éléments pris en charge par cette capacité sont :

Les capacités VMS reposent sur divers moyens matériels pour un fonctionnement efficace. Ces matériels (audio et vidéo) sont essentiels pour la capture, le traitement, le stockage, la visualisation et la gestion des flux de données. Parmi ces moyens matériels, nous pouvons citer les capteurs et périphériques (capteurs de mouvement, microphones, haut-parleurs, etc.), les équipements réseau (switches, routeurs, etc.), ou encore les caméras de surveillance.

3- L’INFRASTRUCTURE 

La capacité Infrastructure concerne les systèmes d’exploitation et de stockage qui supportent les activités industrielles. Les principaux aspects du rôle de l’infrastructure de ce contexte sont :

4- LE PCC (Poste de Contrôle Centralisée)

En plus de ces capacités technologiques, une plateforme SI industrielle doit intégrer un Poste de Contrôle Centralisée (PCC) offrant un cadre où les opérateurs gèrent à travers les capacités technologiques listées les opérations industrielles. Le PCC coordonne également les interventions et prend des décisions en temps réel pour assurer le bon fonctionnement des installations industrielles.

Conclusion

La mise en place d’une plateforme SI industrielle représente une étape cruciale pour la transformation numérique des entreprises industrielles. En intégrant des capacités de SCADA, de gestion vidéo (VMS), de connectivité, et d’infrastructure, une telle plateforme permet de centraliser et d’optimiser la gestion des opérations industrielles. Cela se traduit par une réduction significative des coûts, une meilleure efficacité opérationnelle et une vision en temps réel des processus de production.

Cependant, la réalisation de cette transformation n’est pas sans défis. Les entreprises doivent surmonter des obstacles organisationnels, sécuritaires et techniques pour réussir l’intégration des systèmes existants et assurer une adoption fluide des nouvelles technologies par les opérateurs. La sécurité des données et l’interopérabilité des systèmes sont des enjeux majeurs à prendre en compte pour garantir le succès de cette initiative.