GÉRER SES DÉPENSES CLOUD: UNE INTRODUCTION AU FINOPS
GÉRER SES DÉPENSES CLOUD: UNE INTRODUCTION AU FINOPS
12 décembre 2024
Architecture
Samira Hama Djibo
Consultante
Dans cette ère où les infrastructures Cloud et on premise se côtoient et se toisent, le critère de la rentabilité est déterminant. Cependant là où le Cloud nous promet des économies à petite mais surtout à grande échelle, on peut parfois tomber sur des mauvaises surprises une fois la facture reçue.
Quelle que soit la taille de l’architecture Cloud, on n’est jamais vraiment à l’abri d’un dépassement budgétaire inattendu. Mais en appliquant quelques principes simples du FinOps, on peut arriver à facilement minimiser ce risque.
Comment donc suivre efficacement ses dépenses ? Et comment optimiser financièrement son infrastructure Cloud ?
Nous allons ici nous appuyer sur le Cloud Provider AWS pour étayer nos propos ainsi que nos exemples.
Pourquoi est-ce qu’on peut se retrouver avec des factures plus importantes qu’attendu ?
Une des particularités d’une infrastructure Cloud, c’est qu’il est très facile de commissionner des ressources. Prenons a contrario une architecture on-premise: pour commissionner un serveur physique et installer des machines virtuelles, ce n’est souvent pas une mince affaire. Il faut choisir un fournisseur, lancer la commande et souvent attendre plusieurs mois sans compter d’éventuels problèmes logistiques.
De plus, la commande d’un serveur on-premise est souvent conditionnée par une étude minutieuse des caractéristiques nécessaires du serveur en question et une étude de budget à valider, réétudier etc.
En comparaison, la commande d’un serveur avec les mêmes caractéristiques sur le Cloud se fait en quelques clics, même pour un non-initié, et la disponibilité est immédiate.
La promesse du Cloud, c’est de pouvoir héberger tout aussi bien une architecture basique (comme par exemple un site web statique) qu’ une architecture extrêmement complexe répondant à des besoins spécifiques et des contraintes exigeantes. L’un des principaux clients d’AWS, l’entreprise Netflix responsable de 15% du trafic internet mondial, stocke jusqu’à 10 exaoctets (10 millions de téraoctets) de données vidéo sur le serviceAmazon S3. Ce chiffre inclut les copies stockées dans différentes régions afin d’assurer la haute disponibilité du service ainsi que sa résilience en cas de panne dans un des data centers d’AWS.
Une telle variance des offres et des possibilités que permettent le Cloud rend facile d’allouer des ressources largement supérieures à celles nécessaires, ou souscrire à des options qui, normalement conçues pour des cas très précis, font augmenter votre facture de façon apparemment démesurée..
Qu’on utilise l’interface graphique du Cloud Provider, ou alors un outil d’Infrastructure As Codecomme Terraform ou CloudFormation, sans la maîtrise suffisante au moment de l’allocation des ressources, ou par simple erreur humaine, on peut réquisitionner des ressources largement au-dessus de nos besoins, et donc se faire surprendre par une facture exorbitante.
Pour illustrer ce point, prenons par exemple l’allocation d’une petite base de données via l’interface graphique d’AWS. Pour les mêmes caractéristiques de vCPU et de RAM, en choisissant par erreur, ou en méconnaissance de nos besoins réels, un stockage io2 au lieu de gp2, on multiplie tout simplement la facture par 10 !
Pour bien maîtriser les coûts, il faut donc tout d’abord une bonne maîtrise des termes techniques, du vocabulaire spécifique au Cloud Provider et ne pas se perdre dans des options trop avancées.
Une fois cela pris en compte, il faut noter que ces mêmes cloud providers mettent à disposition des outils qui permettent de facilement détecter et limiter l’impact d’erreurs de jugement ou d’implémentation.
Les solutions mises en place par les cloud providers pour pallier à ce problème
AWS a mis en place le Well-Architected Framework qui sert de guide pour la conception d’applications dotées d’infrastructures sûres, hautement performantes, résilientes et efficientes.
Le framework est basé sur six piliers: excellence opérationnelle, sécurité, fiabilité, efficacité de la performance, optimisation des coûts et durabilité.
Le pilier Optimisation des coûts qui nous intéresse le plus ici est axé sur l’évitement des coûts inutiles.
A toutes les échelles, des services sont mis en place par AWS pour faciliter l’implémentation de ce pilier. Leur connaissance et leur utilisation permettent sans faute d’optimiser le coût de son architecture.
Nous allons voir ici les approches de base qui permettent de s’assurer à un cadrage et une compréhension exhaustive de sa facture cloud et en amont l’optimisation des ressources allouées.
Il existe pour cela trois approches complémentaires:
Surveillance et budgétisation de ses dépenses,
Limitation des accès au strict nécessaire,
Optimisation des ressources avec des méthodes comme par exemple:
Le rightsizing: Le rightsizing est le processus consistant à adapter les types et tailles d’instances ni plus ni moins qu’aux exigences de performance et de capacité de la charge de travail.
Par exemple, cela peut se traduire par le fait de faire appel à de l’auto-scaling qui est la possibilité d’ajouter et supprimer des instances d’une ressources (scalability) ou augmenter et diminuer la taille de ces instances (elasticity) en fonction de l’utilisation en temps réel qui en est faite. Lorsque la charge de travail augmente, plus de ressources sont allouées, et lorsqu’elle diminue, une partie des ressources allouées est libérée.
.
Voici un autre exemple de rightsizing: Dans un projet les environnements de développement et de test sont généralement utilisés uniquement 8h par jour pendant la semaine de travail. Il est donc possible d’arrêter ces ressources lorsqu’elles ne sont pas utilisées pour réaliser des économies potentielles de 75 % (40 heures contre 168 heures).
L’utilisation de Saving Plans & Reserved instances: Prévoir et réserver à l’avance les ressources dont on aura besoin sur 1 ou 3ans permet de faire des économies jusqu’à 72% ! L’utilisation de Spot Instances – des instances éphémères – permet, elle, des économies jusqu’à 90% !
L’utilisation des classes de stockage dont on verra un exemple détaillé plus bas.
Voici quelques pratiques et services incontournables suivant ces différentes approches :
Surveiller et budgétiser ses dépenses
AWS Cost Explorer
C’est une solution de Cost Analysis Dashboard qui permet de voir en temps réel sur une certaine période le total des dépenses par services utilisés.
Exemple d’un Cost Analysis Dashboard
AWS Budgets
AWS Budgets permet de créer des Budgets de dépense et de les exporter notamment sous forme de rapports. Des alertes sont levées et des emails envoyés lorsque les budgets sont dépassés.
AWS Cost Anomaly detection
Grâce au machine learning, AWS peut détecter une augmentation anormales des dépenses qu’il serait plus difficile de repérer manuellement.
Parmi les services de gestion de coûts proposés par AWS, on voit que ceux présentés ici, gratuits et mis en place par défaut, permettent déjà à eux trois d’obtenir une vue assez synthétique de ses dépenses et d’être alerté en cas de potentielles anomalies.
Limiter les accès au strict nécessaire
Un des principes de base qu’il s’agit de sécurité est la limitation au maximum des accès aux ressources au strict minimum et uniquement aux personnes accréditées (principe du RBAC). Ce même principe permet de réserver la création de ressources sensibles qui peuvent, comme on l’a vu, faire rapidement monter la facture aux personnes qui sauront faire bon usage de ces droits..
Que ce soit cloud ou hors cloud, la règle est la même : le least privilege access, c’est-à-dire limiter les droits au strict minimum, en fonction du rôle, du groupe d’appartenance, et même pour les grosses organisations en fonction du département ou du sous compte AWS depuis laquelle la requête est faite.
En plus de monitorer et contrôler ses dépenses, le cloud offre plusieurs possibilités d’optimisation des coûts dont voici un exemple.
Exemples d’optimisations possibles: les classes de stockage
Prenons comme exemple une boite de finance qui stocke les dossiers de leurs clients, tout comme notre géant Netflix sur le service de stockage Amazon S3.
Au début de la procédure, les dossiers sont consultés très souvent, plus le dossier avance, moins ils sont consultés, une fois clôturés ils sont archivés. Chaque année les services d’audit consultent les dossiers archivés. Après 10 ans, ils ne sont pratiquement jamais consultés mais doivent être conservés pour des raisons légales.
AWS met en place des classes de stockage en fonction de la fréquence d’utilisation des fichiers permettant ainsi de réduire les coûts sur les fichiers qui sont plus rarement consultés.
Ainsi nous mettrons les les dossiers en cours dans la classe S3 standard, puis dans la classe S3 Standard Infrequent Accessau fur et à mesure qu’ils sont moins consultés. Une fois le dossier clôturé, nous le déplaçons dans une des classes S3 Glacier à accès instantané ou flexible. Puis une fois la période d’Audit passée, nous les archivons finalement dans la classe S3 Deep Glacier aux coûts de stockage les plus bas.
A noter que nous pouvons également déposer les fichiers directement dans la classe S3 Intelligent Tiering dans laquelle AWS se chargera automatiquement de déplacer les fichiers dans les classes les plus rentables en fonction de l’utilisation réelle constatée.
Par exemple, pour la région Europe(Irlande), les tarifs en fonction des classes sont les suivants :
S3 Standard
S3 Infrequent access
S3 Glacier
S3 Deep Archive
Prix par GB/mois
0,021€
0,011€
0,0033€
0,00091€
Frais de récupération des fichiers ?
Non
Non
Oui
Oui
En analysant le besoin ou en faisant appel aux Intelligent Tiering d’AWS, nous pouvons donc économiser jusqu’à 100% du prix standard de stockage / Gb et par mois pour les fichiers les moins consultés.
Nous avons vu ici une partie des optimisations financières rendues possibles en faisant levier de la puissance du Cloud. Les labs du Well-Architected Framework mis fournis par AWS permettent de voir de façon concrète les voies d’optimisation des coûts présentées par le Cloud provider lui-même.
En plus de l’application des principes essentiels vu dans cet article, vous pourrez creuser facilement le sujet à cette adresse.
En guise de conclusion, je me permets d’appuyer sur le fait que la connaissance à minima basique des principes fondamentaux du FinOps comme décrits dans cet article est essentielle autant au développeur qu’à l’architecte en passant par le management et la finance. C’est uniquement cette collaboration étroite qui permettra une surveillance à toutes les échelles des coûts engendrés et une optimisation financière d’un projet Cloud.
A l’air d’un monde ultra-connecté, toute moyenne ou grande entreprise envisage d’adopter ou exploite déjà au moins une nouvelle technologie telle que l’Internet des objets (IoT), l’Intelligence artificielle (IA), ou encore le streaming. Leur point commun : la gestion des données générées.
Afin de garantir la performance des systèmes, réduire les coûts de stockage, et respecter les obligations réglementaires, il est nécessaire de mettre en œuvre des solutions avancées et appliquer des bonnes pratiques pour absorber et résorber l’augmentation exponentielle des volumes de données.
C’est dans ce contexte que la purge et l’archivage de données jouent un rôle déterminant.
L’objectif de cet article est d’explorer les stratégies efficaces, les outils à implémenter pour soutenir ces activités, et énoncer les avantages de ces deux processus dans une approche de gestion durable des données.
Avant d’aborder les meilleures pratiques, il nous semble indispensable de clarifier ces deux notions fondamentales.
Deux concepts clés
Ces termes sont couramment employés dans le quotidien professionnel du monde IT, mais que signifient-ils ?
La purge physique de données (à différencier de la purge logique) est une opération qui a pour objectif de supprimer définitivement des données obsolètes ou inutilisées afin d’alléger la charge sur les systèmes.
L’archivage de données fait référence à la collecte et au transfert des données vers une plateforme sécurisée pourvue des capacités d’accessibilité et d’intégrité des données.
Bien que distincts, ces deux processus sont complémentaires, mais dans quel intérêt ?
La purge et l’archivage, une perte de temps et d’énergie ?
Une stratégie de purge et d’archivage des données ne se limite pas à simple exercice technique !
Au contraire, ces pratiques apportent de nombreux avantages :
Une meilleure performance des systèmes
Réduire les données, à plus forte raison en Production, améliore la rapidité des traitements.
Une réduction des coûts de stockage
Diminuer les données actives permet d’optimiser l’usage des ressources matérielles.
Une mise en conformité réglementaire
Conserver les données essentielles garantit le respect des normes en vigueur (ex : RGPD, HIPAA) et les politiques internes.
Une maîtrise du cycle de vie des données
Adapter la durée de conservation et la disposition des données favorise leur valeur et leur utilité.
Ces actions tendent donc à améliorer l’efficacité opérationnelle lorsqu’elles sont réalisées de manière proactive.
Quelles actions appliquer à travers ces deux processus afin d’atteindre les résultats mentionnés plus haut ?
Processus de purge et d’archivage
Les étapes structurantes de la purge
Identifier les données obsolètes
Comment reconnaître des données obsolètes ou inutilisées ?
Elles correspondent habituellement à des données redondantes, des fichiers temporaires ou des données anciennes qui n’ont plus de valeur opérationnelle.
Le responsable de l’application, les équipes Projet et Métier doivent tous contribuer à cet exercice. En effet, chacun détient une part de connaissance dans les données interprétées et générées.
Suivant la difficulté, l’identification de ces données peut être automatisée grâce à des outils d’analyse, qui repèrent les fichiers rarement voire jamais consultés.
Une fois les données obsolètes identifiées, il convient de définir des règles précises pour la purge.
Définir des règles de purge : rétention et obsolescence
A quoi correspondent les règles ?
Elles déterminent la durée de conservation des données avant de pouvoir être supprimées, en fonction de critères comme leur date de création, leur dernière utilisation ou leur classification (données sensibles, transactionnelles, etc.).
Ces règles sont alignées avec les exigences de rétention légale, réglementaire ou interne. Il est donc indispensable de réaliser ce travail avec les entités Légale et Juridique, voire la direction Financière de votre entreprise.
Après avoir défini les règles, la purge peut être activée.
Exécuter la purge en assurant une traçabilité et une validation
Ce processus doit être testé (étape importante car certaines actions pourraient être irréversibles !), puis réalisé avec la mise en œuvre d’une traçabilité afin de conserver un historique des données supprimées.
Une étape de validation finale est souvent nécessaire et conseillée pour s’assurer que des données essentielles n’ont pas été accidentellement supprimées.
L’automatisation de la purge peut inclure des étapes de vérification pour garantir l’intégrité des systèmes après l’exécution (par exemple, à travers l’interprétation des tags attribués aux données qui contribue au pilotage de la qualité de la donnée).
Pour les données non utilisées mais qui nécessitent une conservation, il convient de les archiver.
Les étapes clés de l’archivage
Sélectionner les données non critiques
L’archivage concerne les données qui ne sont plus essentielles à l’exploitation quotidienne, mais qui doivent encore être conservées pour des raisons légales, historiques ou analytiques.
Cette étape implique de trier les données pour identifier celles qui peuvent être déplacées vers un stockage de longue durée.
Les données non critiques incluent souvent des fichiers inactifs, des logs ou des versions précédentes de documents.
Une fois les données sélectionnées, il est crucial de choisir le bon support d’archivage.
Choisir un support d’archivage (cloud, stockage physique)
Les options incluent des solutions de stockage en Cloud (par exemple, Amazon S3, Microsoft Azure) ou des solutions physiques comme des serveurs internes ou des bandes magnétiques.
Le choix dépend des exigences en matière de sécurité, de coût et d’accessibilité.
Les données archivées doivent rester consultables en cas de besoin, mais sans impacter les performances des systèmes de Production.
Un plan de rétention doit être mis en place pour gérer la durée de conservation des archives et prévoir leur suppression ou leur migration à terme.
Mettre en place un plan de rétention et de restauration des archives
Ce plan doit aussi inclure des processus de restauration des données, garantissant que les informations archivées peuvent être récupérées facilement (attention à la compatibilité des données archivées avec les versions des outils qui permettent de les consulter !) et rapidement en cas de besoin.
Le temps de restauration des archives doit être en phase avec les besoins de mise à disposition des données : audit, analyse historique, etc.
Enfin, une stratégie de test régulier des archives est également recommandée pour assurer leur intégrité sur le long terme.
Plusieurs solutions techniques existent pour soutenir les processus de purge et d’archivage.
Outils et technologies pour la purge et l’archivage
Aujourd’hui, de nombreuses solutions sont disponibles sur le marché pour répondre aux besoins spécifiques des entreprises, qu’il s’agisse de supprimer des données obsolètes ou de les archiver dans des environnements sécurisés.
Voici un aperçu des principales technologies utilisées pour ces processus.
Solutions de purge
Scripts d’automatisation
Les scripts d’automatisation sont souvent utilisés pour la purge des données stockées sous forme de fichier plat.
Ces scripts peuvent être développés dans des langages comme Python, Bash, ou PowerShell et permettent de planifier la suppression des données obsolètes de manière régulière, tout en minimisant les erreurs humaines.
Ils offrent une grande flexibilité, sont moins coûteux, mais nécessitent des compétences techniques pour leur développement, leur configuration et leur maintenance.
Logiciels de gestion de bases de données (DBMS)
La majorité des systèmes tels que Oracle, SQL Server, ou MySQL intègrent des fonctionnalités de purge automatisée pour interagir avec les bases de données.
Ces outils sur étagère permettent de définir des règles de rétention des données et de planifier la suppression des données dépassant une certaine limite temporelle ou devenues inactives.
Cela aide à maintenir les bases de données à jour, légères et performantes, tout en assurant la conformité aux règles de gouvernance des données.
Outils spécialisés de purge
Enfin, des solutions comme Commvault Data Management, SAP Information Lifecycle Management ou Dell EMC Data Erasure offrent des fonctionnalités avancées pour gérer la suppression des données obsolètes dans les environnements complexes.
Ces outils permettent de s’assurer que la suppression est effectuée de manière sécurisée et traçable, tout en garantissant que les données critiques ne sont pas affectées par inadvertance.
Solutions d’archivage
Solution dans le Cloud
Les entreprises font régulièrement appel à une plateforme de stockage tierce hébergée dans le cloud pour l’archivage des données à long terme.
Par exemple, Amazon S3 (Simple Storage Service), avec ses options comme S3 Glacier ou S3 Glacier Deep Archive, offre des niveaux de stockage à faibles coûts adaptés aux données rarement consultées mais qui doivent rester accessibles en cas de besoin.
S3 permet aussi de définir des politiques de rétention et de restauration faciles à gérer, garantissant la sécurité des données archivées.
Le fournisseur Azure propose quant à lui une solution similaire avec Azure Blob Storage, permettant de stocker des données dans des couches de stockage chaudes (hot), froides (cool) ou archivées selon leur fréquence d’accès.
De manière générale, le niveau d’archivage dans le Cloud offre un espace de stockage très économique pour les données à long terme, avec des options de sécurité avancées comme le chiffrement et la gestion des accès basés sur les rôles.
Solutions sur site (on-premise)
Pour les entreprises qui préfèrent garder leurs données en interne, les solutions de stockage sur site, comme les NAS (Network Attached Storage) ou SAN (Storage Area Network), offrent des options d’archivage robustes.
Les bandes magnétiques restent également une solution fiable et économique pour l’archivage à très long terme. Ces technologies permettent un contrôle total sur les données et sont idéales pour les organisations soumises à des réglementations strictes en matière de confidentialité et de sécurité.
Pour optimiser les coûts de stockage, pensez à compresser (si possible) vos données avant de les archiver !
Data platform is the new Cloud Storage !
Pourquoi ne pas utiliser votre plateforme Data comme option alternative au support de stockage ?
En effet, une plateforme Data accueille déjà les données non essentielles et utiles, et pourrait donc jouer le rôle de lieu d’archivage tout en mettant à disposition les données sous un format anonymisé à des fins analytiques ou pour le machine learning !
Il convient évidemment de conserver ces données dans un état brut (non transformé). De la même manière, un plan de rétention doit être mis en œuvre pour gérer leur conservation et envisager une suppression définitive.
En premier lieu, il est primordial de mettre en place une stratégie de stockage hiérarchisée sur cette plateforme Data !
Enfin, le coût est bien entendu plus élevé qu’un stockage en mode archivage, mais il faut considérer cette solution comme un moyen de valoriser la donnée ! Quels que soient les choix stratégiques en termes de purge et d’archivage, il est important d’être rigoureux sur les actions menées.
Appliquer les bonnes pratiques
Comme en médecine : mieux vaut prévenir que guérir ! Effectivement, les actions de purge et d’archivage ne sont pas sans risque, et il est recommandé de prendre quelques précautions avant de se lancer.
La perte de données importantes
L’un des principaux risques de la purge des données est la suppression accidentelle d’informations critiques ou encore nécessaires pour l’entreprise. Pour éviter cet incident, il est essentiel d’implémenter des mécanismes qui permettent de valider que seules les données réellement obsolètes sont purgées.
Une solution serait de réaliser la purge en deux temps :
Une purge logique : Cette action masque les données et celles-ci sont inaccessibles du point de vue de l’utilisateur ou de l’application
Une purge physique : Passé un certain délai et sans incident remonté et avéré, ces mêmes données sont supprimées définitivement
Garantir l’intégrité des archives
L’intégrité des données archivées est cruciale pour s’assurer que celles-ci restent accessibles, exploitables et conformes à long terme.
Voici quelques pratiques :
Opter pour des technologies d’archivage qui offrent des garanties sur la durabilité des données
Appliquer des mécanismes de chiffrement pour protéger les archives contre les accès non autorisés ou les modifications malveillantes
Choisir une plateforme d’archivage alignée avec les réglementations (GDPR, HIPAA, etc.)
Mettre en place des procédures claires pour restaurer les archives en cas de besoin
Tester régulièrement la récupération des archives, vérifier leur accessibilité et confirmer que les données n’ont pas été altérées par le temps ou l’usure des supports dans le cadre d’une solution sur site
Automatiser et mettre en place un suivi et un audit
Automatiser la gestion des données permet de garantir une purge et un archivage continus et efficaces, tout en respectant les politiques internes et les obligations réglementaires.
Tracer toute action réalisée sur les données et générer des rapports pour homologuer la conformité avec toutes les exigences internes et externes.
Conclusion
La purge et l’archivage des données sont des processus applicables à toutes les strates de l’entreprise, depuis le poste d’ordinateur d’un collaborateur aux serveurs applicatifs en passant par les boîtes email.
Bien entendu, les règles et les consignes sont à ajuster et à appliquer en fonction de la criticité de la donnée présente au sein de ces plateformes.
L’équipe Sécurité de l’entreprise est également partie prenante de ces activités. N’hésitez donc pas à les solliciter ! Purger et archiver sont des écogestes et contribuent naturellement à la sobriété numérique ! Alors, qu’attendez-vous pour les mettre en œuvre ? 🌱
CARTOGRAPHIE SI : Quels acteurs et quelle démarche pour le succès ?
CARTOGRAPHIE SI : Quels acteurs et quelle démarche pour le succès?
2 décembre 2024
Architecture
David Hauterville
Consultant
Puisque pour la gestion pérenne de votre SI, vous avez saisi tout l’intérêt de l’architecture d’entreprise, vous avez réalisé l’importance d’avoir une cartographie à jour de votre patrimoine. La mise en place et le maintien de ces données centralisées ne se résument pas à l’acquisition ou au développement d’une application.
La solution technique de cartographie doit se déployer dans un environnement où les acteurs et les moyens s’anticipent et s’adaptent en fonction des objectifs souhaités face aux réalités rencontrées. Quelle que soit la solution utilisée ou envisagée, il faudra faire face aux différents défis qui se dressent lors de son déploiement. L’outil doit s’implanter dans un contexte propice à sa prise rapide et son implantation durable.
Nous allons donc d’abord vous présenter les différents acteurs d’une démarche de cartographie réussie, du sponsor aux responsables du run, pour ensuite vous proposer une démarche issue de notre expérience auprès de nos différents clients.
Source : Pexels – Brett Sayles
Les acteurs d’une démarche de cartographie réussie
Un sponsor fort, une tête de proue
C’est l’ incarnation du projet consciente des moyens, du temps, de l’énergie qu’il sera nécessaire d’y consacrer. C’est le moteur qui fournit les conditions et prend les décisions sur les efforts à adapter à chaque phase du déploiement (sur plusieurs mois à quelques années).
Il est haut placé dans le board ( DSI …) pour ouvrir les portes et parler du projet dans les instances de gouvernance de haut niveau (ex: des réunions de directeurs).
Un product owner dédié à la solution
C’est idéalement un profil d’architecte expérimenté en mesure de rapporter au sponsor l’état d’avancement et les points d’alerte. Il est garant du produit et capable de comprendre les organisations et leurs enjeux. Il sera sera à même de définir les quick wins du référentiel, la démarche et l’organisation qui en découle. Il se doit d’être force de communication proactive tout en sachant se rendre disponible pour adresser les demandes d’accompagnement issues de toutes les entités de l’entreprise.
Des responsables désignés au suivi des applications
Les responsables d’application sont chargés de garantir la fraîcheur des informations relatives aux applications dans le référentiel. Ils sont idéalement en accès direct avec les utilisateurs de ces applications. Ils vont former une communauté d’échanges autour des bonnes pratiques de récolte des informations et l’utilisation de l’outil de référencement. Ils se feront les relais de l’effort de sensibilisation et d’accompagnement au bénéfice de l’usage du référentiel.
Des sachants identifiés
Parfois elles-même responsables d’application, ces personnes font office de sachants concernant l’historique du patrimoine applicatif. Elles sont souvent une mémoire vivante de l’évolution des applications et de l’organisation (historiques des contraintes et décisions). Elles contribuent à identifier les référentiels déjà présents. Depuis quand existent-ils, pour quels objectifs et usages, pour quels usagers et quelles en sont les limites et les points de douleurs.
Une équipe Build
En pointe de la connaissance et de la maîtrise de l’outil, elle construit le métamodèle des données et implémente les fonctionnalités nécessaires à l’exploitation de l’outil. Elle entretient une relation rapprochée auprès de l’éditeur. Elle teste et approuve l’activation, voire la création, des nouvelles fonctionnalités. Elle s’assure de tirer le meilleur parti des montées de version et mise à jour éditeur.
Une équipe Run
Au plus près des contributeurs et utilisateurs, elle assure leur accompagnement technique. Elle gère l’administration et le paramétrage de l’outil. Elle veille aux bonnes performances du service pour garantir un confort d’utilisation optimal.
Au début du projet, les fonctions Build et Run sont confondues.
Les étapes successives d’une démarche de cartographie réussie
Les fondamentaux, des chantiers à lancer les uns après les autres
La mise en place de la comitologie ad hoc
Dans l’optique d’améliorer la démarche en continue, les acteurs du projet doivent être prêts à consacrer du temps pour suivre la comitologie :
Entre le sponsor, l’équipe de build et l’équipe de run.
Avec la communauté des responsables d’application.
Avec les métiers.
Avec les utilisateurs.
Avec les concepteurs/éditeurs de l’outil.
Un métamodèle initial
Il s’agit de définir les objets à référencer dans l’outil. Une bonne base de départ est constituées des objets suivants:
Profil utilisateurs : souvent représenté par les entités organisationnelles, identifie qui est impacté par la vie des applications qu’ils utilisent et/ou dont ils sont propriétaires.
Capacité métier : souvent inspirée des Plan d’Occupation des Sols ou de Standard du métier, représente les fonctions métiers à couvrir par les applications.
Application : objet au centre du référentiel, en lien avec chacun des autres objets.
Données : manipulées ou échangées par l’application.
Flux : matérialise l’échange de données entre applications.
Brique technologique: dont se sert l’application pour fonctionner.
Si pour la plupart des objets, leur définition paraît évidente, certaines, comme celle des capacités métier hors standard ou surtout celles de l’application, peuvent faire débat. De même les attributs à renseigner pour chacun des objets est potentiellement sans limite. Le métamodèle initial pose les hypothèses de définition les plus simples et inclusives possibles. Seuls les attributs essentiels aux rapports et analyses prioritaires sont retenus pour les premières collectes.
Une première campagne de collecte savamment orchestrée
Une fois ces éléments identifiés, il est alors possible de lancer la première itération de collecte des données identifiées dans le métamodèle initial. Elle est circonscrite à un périmètre limité, pour une entité perçue comme représentative et une période réduite à maximum trois semaines à la façon d’un sprint en mode Agile. Durant cette période les interlocuteurs clés identifiés sont sûrs d’être disponibles. Donc éviter les périodes propices aux congés, audits, bilans réglementaires, etc.
Cette première collecte est la matière première à soumettre aux processus et méthodologies à mettre en place pour l’harmonisation et l’optimisation du référencement. Elle peut être complétée par une deuxième ou troisième campagne afin de valider les hypothèses de modélisation et de modalité de collecte.
Un guide de la modélisation partagé à tous
Une fois cette première campagne réalisée, vient le moment de partager à tous une base documentaire.
Les processus doivent avoir pour but de rendre l’information disponible et compréhensible pour tous par un maximum d’intervenants à leur échelle. Afin de s’assurer que tous parlent le même langage, il est donc indispensable de rédiger le glossaire de l’organisation.
Ce glossaire sert de socle pour l’élaboration des règles de nommage (application, flux,…) et conventions de traitement de cas (modalité de prise en compte des applications, flux hors SI de l’organisation,…) à mettre en pratique lors de l’exploitation des informations collectées.
Cette documentation est tenue à jour à l’occasion de revues régulières en fonction de leur efficacité. Elle se nourrit de l’épreuve du concret et des suggestions rencontrées sur le terrain.
Cette documentation s’illustre sous la forme d’un guide utilisateur personnalisé du portefeuille d’application, même (surtout!) si c’est une solution du marché.
Un temps sacralisé pour la formation
Une fois les leçons des premières campagnes tirées et transcrites dans la documentation, il est temps de décentraliser progressivement la saisie des informations vers les responsables identifiés. Il est indispensable de leur dédier le temps nécessaire à la montée en compétence sur l’outil. Veillez à ce que l’éditeur soit en mesure de vous accompagner sur les fondamentaux et les impacts des mises à jour. Avec le renfort d’une prestation externe, l’équipe bénéficie de son expérience agnostique, d’une détection des limites de la solution au-delà du marketing, de propositions hors du paradigme propriétaire.
Une stratégie de suivi des objectifs
Au fur et à mesure que la collecte s’intensifie, le référentiel s’élargit en termes d’entités organisationnelles couvertes, ainsi qu’en quantité, variété, et qualité des données tout en faisant évoluer son métamodèle . Cet élargissement doit être maîtrisé et soutenu. La maîtrise se matérialise par le choix, la revue et la planification des objectifs afin qu’ils restent atteignables et porteurs de valeur pour les utilisateurs. Le soutien passe par la mise à disposition des moyens évoqués plus tôt : documentation, guide méthodologique, session régulière d’information et de formation, animation de la communauté mais aussi l’automatisation des processus.
Le suivi de l’évolution de la couverture est effectué via un tableau de bord personnalisé en fonction des besoins de l’organisation. Y sontrassemblés des indicateurs quantitatifs (nombre de fiches référencées, nombre d’utilisateurs, … ) et qualitatifs (taux de complétude des fiches, fraîcheur des données).
Penser à célébrer régulièrement les jalons atteints avec succès via des canaux de communication internes ( newsletters, workplace,…).
À ce stade de l’implémentation, nous recommandons d’officialiser la distinction :
équipe de Run qui s’occupe du suivi des indicateurs
équipe de Build qui reste dédiée à l’amélioration continue de l’outil.
Un événement annuel pour faire le point
Le suivi par tableau de bord se complète par une revue de patrimoine a minima une fois par an. Durant une période de plusieurs jours, les conditions sont créées pour que tous les acteurs concentrent leurs efforts sur :
la mise à jour du référentiel,
la mise à jour de leur compétence et de leur connaissance sur l’outil,
la mise en commun de leurs retours d’expérience et bonnes pratiques,
la remontée des doléances.
L’événement peut combiner différentes formes : défis, concours, hackathon, tout mode d’implication pour rassembler le plus large spectre possible d’utilisateurs.
C’est l’occasion de mettre en lumière d’une part, les événements et les acteurs qui ont marqué la saison qui vient de passer; et d’autre part d’afficher les ambitions et les nouveautés de la saison à venir.
Les étapes pour aller plus loin
Des connecteurs pour les bases existantes
Une étape dont l’importance nous pousse à la mettre dans les fondamentaux, mais dont le planning associé n’est pas toujours compatible avec les ambitions. Mais tirer parti automatiquement des autres sources de données en production est un énorme gain de temps et de fiabilité sur le moyen-long terme. C’est pour cela que cette initiative doit être réfléchie au plus tôt. Dès que possible il faut s’interfacer avec les autres référentiels à disposition : CMDB, Plateforme d’échanges, Data, Achat, RH, Portefeuille des projets, … Cette stratégie permet d’enrichir et maintenir à jour le patrimoine avec des sources automatiquement croisées. Cependant, avant de mettre en place ces interfaces, certains prérequis sont nécessaires à une intégration efficace :
le modèle du référentiel de cartographie est stabilisé
La golden source est identifiée pour chaque donnée partagée.
Les équipes techniques de chaque outil ont les ressources nécessaires en interne et auprès des éditeurs pour mener à bien les intégrations.
Des règles de cohabitation organisationnelle
Plus la cartographie s’étend, plus elle se confronte à des revendications qui peuvent remettre en cause l’homogénéité du modèle global. Il est alors temps de penser à comment évaluer les critères de granularité et de segmentation. La plupart des critères dépendent des profils utilisateur. La segmentation peut s’opérer par :
son entité organisationnelle (division, filiale,..),
son groupe fonctionnel,
sa langue,
sa région géographique,
…
Cette liste est non exhaustive et ses éléments sont combinables.
Des marqueurs de réussite!!
Avec ces acteurs et cette approche vous êtes sur la voie de la pérennisation de la cartographie. Quelques signes qui montrent que l’implémentation de votre outil de cartographie est un succès :
Ses utilisateurs sont passés du statut de « remplisseur de fiche » à « responsable impliqué dans la qualité des informations» et se font ambassadeurs de l’outil.
Ses utilisateurs peuvent spontanément partager les bénéfices dans leur cas d’usage.
Son évolution continue indépendamment du sponsor.
Son statut de source de vérité de la connaissance de l’architecture d’entreprise.
Son existence et son intérêt sont reconnus par tous les collaborateurs.
Son statut de point de départ et d’arrivée de projets de transformation.
Le référentiel ainsi complet et à jour, se révèle être un puissant facilitateur de préparation et de suivi d’exécution des projets de transformation.
En conclusion, le suivi ordonnancé de ces étapes et la mise en place de ses acteurs, vous permettra d’installer une cartographie adoptée par les utilisateurs clé du maintien de votre SI, dans les meilleurs délais. Dans cette course contre la montre face aux exigences de réactivité de votre SI , certains raccourcis peuvent se révéler plus coûteux à long terme que le bénéfice perçu à court terme. Chez Rhapsodies Conseil, fort de notre expertise en gestion de Patrimoine et Gouvernance SI, nous restons à votre disposition pour vous guider sur ce parcours stratégique vers le succès.
À Rhapsodies Digital, on aime construire des solutions numériques (oui oui), et on s’est dit qu’on avait envie de partager dans le détail ce qu’on fait. C’est donc avec une série d’articles que l’on va soulever le capot, et présenter les détails techniques de nos travaux.
On va commencer par parler de notre projet Solertia (car il est tout frais, le MVP vient de sortir), de son archi, le back, le front, et de comment on a fait tout ça.
Solertia, projet visant à lister, catégoriser et présenter des entreprises au savoir-faire exceptionnel, est aussi notre premier vrai projet interne, imaginé et réalisé par une équipe très réduite, mais passionnée !
À première vue, le projet présente une architecture très classique, avec un socle API et base de données consommée par un front.
L’avantage, c’est que si, un jour, on a envie d’exposer et de monétiser nos données, c’est presque déjà fait (bon, moyennant un système d’authentification et de rate-limit bien évidemment…). Et ça tombe bien, car c’est également une des ambitions du projet.
Autre avantage, notre front n’étant qu’une couche de présentation, il ne fera pas d’écriture sur nos données, tout comme les clients potentiels de notre API, on peut donc, sans vergogne, couper en deux nos routes et ajouter une protection supplémentaire sur tout ce qui est POST/PUT et DELETE.
Notre API/Back, sera de plus un proxy pour récupérer et agréger de la data sur nos fameuses entreprises, avec notamment des connexions API avec Pappers (et d’autres sources de données qui arriveront par la suite).
C’est pour cela que le full monolithe (bien qu’avec beaucoup d’avantages, on le rappelle, utilisé par exemple chez Stackoverflow), n’a pas retenu mon attention ici.
Le choix de l’ennui : côté base de données
TL;DR : j’aime bien PGSQL.
Une de mes technos préférées, je dois l’admettre, est PostgreSQL. Robuste, ultra-performante, sécurisée et éprouvée, les nombreuses qualités de cette base de donnée relationnelle open source ne sont plus à présenter.
Son excellente gestion du JSON, avec bon nombre de fonctions et d’opérateurs prêts à l’emploi (on en parlera plus en détails sur la partie backend), peuvent permettre, par exemple, de créer des requêtes dont le résultat est directement mappables sur un DTO.
Concernant le volume de données, quelques milliers d’entreprises, il me paraissait overkill d’utiliser ElasticSearch pour l’instant (qui nécessite son serveur et donc sa maintenance — ou alors des solutions SaaS hors de prix (coucou Algolia/Melisearch)), sachant que PG dispose d’un excellent module de recherche fulltext.
Puisqu’on a évoqué un peu de NoSQL, je n’ai pas retenu cette solution non plus, car on a quand même pas mal de relations à gérer, et n’étant pas non plus un fana des micro-services (quand ce n’est pas nécessaire), je n’avais pas envie de m’embêter à ce niveau-là. PostgreSQL est mon choix rationnel, par défaut, quand je cherche une base de donnée.
Car oui, il faut le reconnaître, le NoSQL est sexy et a d’autres avantages, et match très bien quand on a moultes services qui ont leur propre système de stockage. Mais bien souvent, ce n’est qu’une question de préférence sur la modélisation, au final, on peut très bien faire du NoSQL sur PG.
Comment qu’on se cache
TL;DR : un jour oui, mais pas maintenant.
Actuellement, le projet ne dispose pas d’un système de cache applicatif, autre que ce que les technos choisies font nativement. Nous verrons après le lancement du projet, car on aime bien itérer et donc pour l’instant, on préfère avoir notre BDD en frontal de notre API.
Parce que oui, développer un système de cache, ce n’est pas auto-magique, il ne suffit pas d’installer l’excellent Redis et hop, c’est fait. Il y a du code à écrire, et pas mal de cas à gérer, ainsi qu’une dépendance et un serveur supplémentaire.
Parlons technos applicatives !
Le choix du compilé côté Backend
S’il y a bien une chose que j’ai comprise au cours de mes derniers projets, c’est que l’interprété, c’est pratique, mais c’est coûteux en performance et donc en serveur.
Côté API, il est absolument vital que les performances soient au RDV, car c’est notre backend, c’est ce qui va exposer nos données, et c’est ce qui sera le plus gros bottleneck de notre architecture.
Ce que j’aime bien avec les exécutables, c’est qu’après avoir target une plateforme, on a pratiquement besoin de rien sur le serveur pour le faire tourner, couplé avec supervisord par exemple, on peut également avoir rapidement un système simple, auto-gérable. Le choix de docker en prod est par ailleurs plus envisageable, il suffit d’une alpine vanilla et c’est parti.
Les choix évidents : Rust vs Go
Secrètement, cela fait des années que je me forme au langage Rust, que j’adore et dont j’admire le design. Gestion de la mémoire fine sans garbage collector, syntaxe élégante, typage strict, friendly compilateur, zero-cost abstractions et performances proches du C/C++.
Néanmoins, son gros (et peut-être seul ?) défaut reste son niveau d’adoption professionnelle. Bien qu’on dénombre de plus en plus de success story après un passage à du Rust (Discord, AWS, Kernel Linux, 1Password…), le nombre de développeurs est actuellement limité, et la gymnastique mentale nécessaire pour coder en Rust est importante.
Je suis convaincu que le jour où on sera plus nombreux, je pousserai fort pour que l’on puisse construire nos backend en Rust pour participer également à la popularisation de ce langage.
Surtout que tokio (les créateurs de l’async sur le langage), avance à grands pas avec son framework web ultra-performantaxum, qui je pense va tout éclater sur son passage. À l’heure où j’écris ces lignes, le projet est en v0.9.3.
Le vainqueur rationnel : Go
Et donc oui, spoiler alerte, le backend de Solertia est écrit en Go.
Rebuté par sa syntaxe dans un premier temps, loin d’être élégante, force est de constater que le langage est populaire. Certainement causé par la réécriture de pas mal de backend PHP/Nodejs/Java et avec un Google en back.
Il s’est rapidement imposé, comme un bon compromis simplicité d’utilisation/performances.
Bien qu’on s’écarte sensiblement des performances de Rust, il est sympa de voir que des calls API sont de l’ordre de la milliseconde, avec des appels BDD derrière de la transformation de data. Surtout une belle économie de CPU/RAM, juste parce qu’on utilise mieux les ressources et qu’on a besoin de peu de dépendances (genre curl en fait) sur le serveur.
Côté langage, Go est également typé strictement et se veut surtout une boîte à outils complète côté network. Et là oui, pour faire du web, c’est simple, nativement tout existe déjà dans le STD. De plus, sa gestion de la concurrence le rend très cool à utiliser.Côté librairies/framework, on est aussi très bien, avec bon nombre de choses qui existent (forcément, car le gros du truc est déjà présent dans le langage). Ici, on va juste teaser, en disant qu’on a un framework web (Gin), un semi-ORM un peu naze, mais pratique pour les migrations (Bun) et un truc génial pour auto-générer la documentation OpenAPI à partir de nos DTO d’entrée et de sortie (Huma).
NodeJS et Astro pour le front
Je vais vous l’avouer, je n’ai jamais été très grand partisan de NodeJS (étant plus côté PHP historiquement).
On peut néanmoins reconnaître que son extrême popularité a généré tout un tas de truc quand même bien cool comme Typescript et Astro, excellent framework web que l’on m’a fait découvrir très récemment (big-up à Renaud qui se reconnaitra s’il est dans les parages !). Et également, côté performance, il ne se défend pas si mal que ça. Le souci, c’est qu’on paie ça avec un nombre absolument dingue de dépendance nécessaire.
Mais l’histoire de ce choix est, en réalité, un peu plus complexe que ça.
Un truc que fait très bien Astro, c’est la génération d’un build statique (du pur HTML/CSS avec un très peu de javascript côté client). Et ça, pour le coup, j’aime bien, car ça me rappelle le côté exécutable, presque ennuyeux, prêt à l’hébergement sur un bucket (par exemple), avec 0 dépendances côté serveur et des performances forcément extraordinaires.
Le seul “soucis”, c’est que c’est complexe à mettre en place quand on a du contenu dynamique. On n’a ici pas des masses de choix :
Option A : On (re)génère des portions ou l’intégralité du site via des Hook et autre système automatisé dès que la data change.
Option B : On fait nos appels API côté client.
La deuxième solution ne me plait guère, car cela veut dire que si on veut implémenter un rate-limit pour protéger et monétiser notre API, les conséquences seront subies côté client (ou alors, on ajoute un BFF, mais ça nécessite une autre app et donc de la complexité), et qu’on va nécessairement perdre de la performance et donc l’intérêt d’un build statique.
Donc, je suis plutôt partisan ici de la première solution, sauf que c’est quand même assez compliqué à mettre en place, surtout qu’on a, en plus, un moteur de recherche à implémenter (oui, des solutions pour le build statique existent, mais on verra plus tard !).
Limités par le temps et les ressources de développement, on va donc la jouer interprété côté serveur, avec les technos qui permettent de générer un static, et on migrera vers cette solution par la suite, ça, c’est certain.
Et PHP alors ?
Croyez-moi bien qu’avec mes 8 ans d’xp en développement PHP/Symfony (et j’adore le langage depuis sa version 7), cette piste a été étudiée, finalement rejetée, car j’avais envie d’expérimenter d’autres choses, principalement pour ouvrir mes chakras (bien qu’elle fonctionne très bien !).
De plus, pour la génération de build statique (qui est, rappelons-le, notre cible idéale), on a des solutions qui sont, selon moi, bien moins éprouvées que côté NodeJS. Et de toute façon, on a de l’interactivité forte côté UI, donc on aura forcément besoin de JavaScript.
Le Backoffice
Ce qu’on a dit jusqu’à présent, c’est super, mais il faut quand même à un moment pouvoir administrer nos données, car ça ne se fait pas tout seul (dommage…).
Et bon, ouvrir un éditeur de base de données et faire les modifs comme ça, directement en prod, c’est bien nature, un peu trop à mon goût.
Le p’tit soucis, c’est que faire un back-office, c’est pénible car :
Peu de valeur quand il s’agit d’un CRUD classique (c’est notre cas).
Peu de valeur quand c’est en usage interne, on ne va pas le vendre ni le faire utiliser à d’autres personnes (c’est notre cas).
Les formulaires ajoutent toujours de la complexité, d’autant plus que ça prend du temps.
Oui, on a plein de générateurs de BO qui existent pour se simplifier la vie, mais cela reste une app et donc un truc à maintenir.
Si seulement il existait des solutions qui permettent de faire du drag & drop de composants, de gérer l’authentification et les droits des utilisateurs, de créer des formulaires en 4 clics, plug & play sur n’importe quelle API, ça serait vraiment cool pour notre use case !
Grâce à cet outil et à sa version gratuite, on a pu monter un BO en quelques jours, autour des endpoints d’écriture de notre API. Sa base est solide pour faire des formulaires et des listings simples, sur les résultats de notre API. On définit les endpoints, on map les champs sur les inputs et pouf, ça marche.
Après, il y a quand même des désavantages par rapport à un BO développé maison, certaines choses m’ont bien frustré, comme l’absence de gestion avancée des images par exemple, car le système ne propose qu’un bête input d’upload de fichier, exit donc les jolis croppers et les résolutions fixes en fonction du champ.
Une infra (plutôt) simple
Avant de terminer cet (long) article, j’aimerais tout même partager quelques mots sur l’infra choisie pour l’hébergement du projet.
Étant très sensible à la philosophie Dev Ops, mais avec des connaissances limitées en Infra as Code (IAC) et en administration réseau, j’avais tout même envie d’un environnement propre avec, surtout, de la facilité au niveau du déploiement. L’IAC puisqu’on en parle, est, selon moi, l’un des aspects les plus importants à mettre en place, parce qu’elle constitue une description exhaustive de ce qui est online.
Côté hébergement, cela fait maintenant quelques années également que j’évolue dans des environnements “cloud”, où l’approche budgétaire et la grande flexibilité sous-jacente permettent d’appliquer l’agilité et l’itération plus facilement au domaine du système, notamment encore fois, lorsque les forces vives sont réduites. Il était donc naturel pour moi d’implémenter ces outils pour Solertia.
Le Cloud de Scaleway
Etant plutôt à l’aise avec les services d’AWS, j’ai également voulu innover, et de tester les services de Scaleway, qui est européen par nature.
On retrouve tout ce qu’il faut pour construire ce que l’on désire ici :
Containers “serverless” pour pousser des images docker en prod, sans s’embêter avec Kubernetes (quelques défauts néanmoins, comme un manque de flexibilité sur les paramètres de l’autoscaller, et des healthcheck abstraits).
Containers registry et Bucket (compatible API AWS S3!) pour sauvegarder nos artifacts, backends terraform et par ailleurs assets statiques comme les images.
Base de données managée PGSQL (uniquement en v15 malheureusement, alors que la 16 est dispo depuis presque un an).
SDK terraform plutôt bien documenté, qui m’a permis, en ma qualité de gros n00b de cette techno, de faire mon IAC de façon plutôt fluide.
Monitoring natif sur Grafana, plutôt fourni.
Comme décrit plus haut, j’aime itérer et faire vivre l’architecture, ici, on ne présente que ce qui propulsera le MVP. Il est possible que cela change dans le futur (pourquoi s’en priver ? c’est un des aspects sympa qu’offre le cloud).
Docker couplé avec une CI/CD chez Gitlab
Bon c’est super tout ça, mais je n’aime pas spécialement l’idée de construire mes images docker sur mon poste et de les mettre en prod via la console UI de Scaleway.
Fort heureusement, nous utilisons Gitlab, qui avec sa puissante et beginner-friendly CI/CD m’a permis de mettre en place, pour les deux projets :
La chaîne de lint, test et build
La partie déploiement avec upload de l’image sur le registry, modification du projet terraform avec nouvelle version, apply et migrations, base de données (uniquement côté API).
Le cycle quant à lui est honteusement simple : À chaque nouvelle branche, la CI nous dit si c’est bien (ou pas, très objective qu’elle est), et à chaque nouveau tag sur main, ça déploie.
La full picture
Pour conclure, ce qu’il va falloir améliorer
Voici une mini-liste non exhaustive de ce que j’ai mal/pas fait, et que j’aimerais donc pousser par la suite :
L’auto-scalling et healthcheck côté containers, trop obscure actuellement.
Le cache, mais on en a déjà parlé.
Instant T-Shirt XXL : Faire un build statique pour le front, et donc enlever un serveur traditionnel.
Merci de m’avoir lu !
Écrit par Antoine Belluard – Responsable technique chez Rhapsodies Digital, j’ai une dizaine d’années d’expérience dans le développement informatique. Passionné par la programmation et la technologie, et poussé par un fort impostor-syndrome, je suis en apprentissage continu.
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 ?
Les données exposées sont très souvent sensibles : Les API renvoient souvent des données confidentielles, rendant leur protection indispensable.
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.
Leur complexité est croissante : L’évolution des architectures (microservices, coud, service mesh, …) peut augmenter la surface d’attaque potentielle.
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.
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
L’injection SQL par exemple,
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 :
Les sessions doivent être bien gérées : Sessions non expirées ou mal révoquées.
Les tokens d’accès doivent être bien sécurisés : Stockage ou transmission non sécurisée des tokens.
Les contrôles d’accès doivent être bien configurés: Permissions mal configurées permettant des accès non autorisés.
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 réponses API sont trop verbeuses : Inclusion de données non nécessaires dans les réponses.
Les réponses API ne sont pas chiffrées : Transmission de données en clair.
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 :
Elles peuvent être automatisées à grande échelle.
Elles peuvent aussi exploiter des informations d’identification provenant de fuites de données (évitez d’avoir un seul mot de passe…).
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 :
Le vol de données sensibles : En interceptant des données non chiffrées.
La manipulation de requêtes : En altérant des données échangées entre le client et le serveur.
L’usurpation d’identité : En récupérant les certificats serveurs pour se faire passer pour le serveur légitime.
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 :
Les attaques volumétriques : En saturant la bande passante.
Les attaques au niveau applicatif : En utilisant des vulnérabilités de l’API pour épuiser les ressources du serveur.
Les attaques lentes : Cela consiste à maintenir des connexions ouvertes pour épuiser les ressources du serveur.
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é :
La complexité exponentielle de la gestion des accès : On doit gérer les exigences de sécurité par microservice.
Les risques liés à l’orchestration des conteneurs : Les outils d’orchestration peuvent avoir aussi leurs propres vulnérabilités.
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 :
La mauvaise configuration des services cloud : Exposition involontaire d’API ou de données.
La gestion des identités et des accès complexifiés : Il est nécessaire d’intégrer les mécanismes de sécurité de son cloud provider avec ceux de son API.
La dépendance vis-à-vis de la sécurité du fournisseur cloud : Il est nécessaire de comprendre et de compléter les mesures de sécurité, selon la politique de son cloud provider.
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 :
Le manque de visibilité : Ce qui engendre des difficultés à identifier et à sécuriser ces API.
Les vulnérabilités non corrigées : Les API obsolètes peuvent contenir des failles de sécurité connues.
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 :
Le Shift-left security : Qui intègre les tests de sécurité dès le début.
L’automatisation des tests de sécurité : Grâce à des outils d’analyse de code statique (SAST) et dynamique (DAST).
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 :
La définition de standards de sécurité : Via documents de bonnes pratiques de développement et de déploiement d’API sécurisées.
La gestion des accès et des identités (IAM) : Pour couvrir la définition de politiques strictes pour l’authentification et l’autorisation.
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 :
Des programmes de formation : Via des sessions dédiées sur les pratiques de sécurité des API.
Des exercices pratiques : Via des simulations d’attaques et de réponses aux incidents.
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 :
En filtrant du trafic : Via blocage des requêtes malveillantes.
En gérant les authentifications : En centralisant et en renforçant les mécanismes d’authentification.
En faisant du rate limiting : En protégeant contre les attaques DDoS.
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 découverte automatique des API : Afin de détecter les fameuses Shadow API.
Solutions d’analyse comportementale : Afin de détecter les anomalies et des comportements suspects.
Solutions de gestion des versions : Afin de contrôler et de sécuriser les différentes versions d’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 :
Les scanners de vulnérabilités spécifiques aux API : Comme son nom l’indique.
Les solutions de fuzzing d’API : Le fuzzing est une technique de test envoyant des données aléatoires et/ou malformées pour identifier les failles.
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
Via utilisation de protocoles standards : OAuth 2.0, OpenID Connect.
Via gestion fine des autorisations : Via implémentation du principe du moindre privilège, au travers des API scope.
Via rotation régulière des clés et tokens : Pour limiter l’impact en cas de compromission.
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 :
Point d’entrée unique : Centralisation du trafic API pour une meilleure visibilité et un contrôle accru.
Gestion des versions : Facilitation de la gestion des différentes versions d’API.
Transformation et médiation : Adaptation des requêtes et des réponses pour assurer la compatibilité et la sécurité.
2.3.3 Chiffrement et protection des données
Chiffrement en transit : En utilisant systématiquement le TLS (dans une version non dépréciée). Possiblement aussi signer les données échangées, comme le peut faire Stripe avec son API afin de garantir leur authenticité, intégrité et non-répudiation.
Chiffrement des données sensibles : Que ce soit des données au repos ou en transit.
Gestion sécurisée des clés : En gérant les clés de chiffrement tout au long de leur cycle de vie. Il s’agit notamment de :
l’utilisation de clés solides, générées de manière aléatoire.
la rotation régulière des clés afin de limiter l’impact des violations potentielles.
stocker les clés en toute sécurité dans des “Vault”, séparément des données qu’elles protègent.
mettre en place des contrôles d’accès.
gérer les identités numériques via des certificats grâce à une PKI, couplé à
un HSM pour sécuriser des clés cryptographiques dans un environnement matériel.
2.3.4 Gestion des logs et audit
La journalisation : En enregistrant tous les événements liés à la sécurité.
La conservation des logs : En conservant les logs pendant une période suffisante pour permettre des analyses dans le passé.
L’analyse régulière des logs : En mettant en place des processus d’analyse régulière des logs.
La protection des logs : En empêchant toute modification non autorisée pour garantir leur intégrité en cas d’audit.
2.3.5 Surveillance en temps réel
L’analyse comportementale : Pour détecter les anomalies dans le trafic API.
Les alertes en temps réel : Pour réagir rapidement aux incidents de sécurité.
Le monitoring continu : Pour surveiller en permanence la disponibilité des API et détecter rapidement les attaques.
2.3.6 Tests de pénétration et validation de la sécurité
Des tests réguliers.
Des scénarios réalistes qui s’inspirent de cas réels.
Une validation continue via la chaîne CI/CD.
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.
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.
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.
