La séparation des métadonnées et du contenu permet de mettre en place une architecture évolutive et performante.
La plupart des systèmes documentaires d’entreprise sont lourds et lents parce qu’ils traitent chaque document comme un seul bloc, métadonnées et contenu étant regroupés. C’est inefficace. Vous n’avez pas besoin d’ouvrir l’intégralité du fichier pour obtenir des informations de haut niveau. Lorsque vous recherchez des données telles que les types de contrats ou les dates de création, vous ne recherchez que des métadonnées. Le contenu, le fichier lui-même, n’a pas besoin d’être touché. Cette distinction change tout.
Nous avons donc séparé les métadonnées et le contenu dans des systèmes distincts. Cela nous a donné la possibilité d’optimiser chacun d’entre eux de manière indépendante. Les métadonnées sont déplacées vers des bases de données NoSQL à grande vitesse telles que DynamoDB, Firestore ou Cosmos DB, toutes conçues pour des lectures et des écritures rapides et à haut volume. Le contenu, quant à lui, est stocké dans un système de stockage d’objets comme S3, Azure Blob ou Google Cloud Storage. Ces systèmes sont conçus pour gérer d’importants transferts de données, et ils le font bien.
Les performances ont immédiatement augmenté. Les temps médians d’interrogation des métadonnées ont été ramenés à environ 200 millisecondes. Même au 95e centile, la latence est restée inférieure à 300 millisecondes, tout en traitant 4 000 requêtes par minute, sans aucune erreur. C’est une solution stable, réactive et durable.
Cette approche résout également le problème de l’échelle. Au fur et à mesure que le volume de données augmente, les deux systèmes, métadonnées et contenu, évoluent horizontalement d’eux-mêmes. Vous n’êtes pas obligé de réorganiser votre architecture pour faire face à l’augmentation de la charge. C’est propre et ça marche.
La conception privilégiant les API permet de séparer les charges de travail et d’assurer une évolution indépendante du système.
Le découplage de vos charges de travail ne signifie rien si vous ne l’appliquez pas dans votre interface, et c’est là que la plupart des architectures échouent. Nous avons construit une couche d’API qui rend impossible le mélange accidentel de contenu et de métadonnées. Vous voulez des métadonnées ? Vous utilisez l’API des métadonnées. Vous voulez le fichier du document ? Il y a un autre point de terminaison pour cela.
Cette limite architecturale ne se contente pas d’améliorer les performances. Elle crée une structure. Elle facilite la sécurisation, la validation et la mise à l’échelle. Les appels liés aux métadonnées vont directement à la base de données, de manière rapide et légère, sans flux de fichiers. Le contenu du document n’est touché que lorsqu’il est explicitement demandé.
Le fait d’avoir des points de terminaison clairement définis permet également de se prémunir contre l’avenir. Cela permet au frontend et au backend d’évoluer sans avoir à réécrire votre système à chaque fois que quelque chose change. C’est la flexibilité à l’échelle.
D’un point de vue opérationnel, l’API est également la surface de contrôle pour tout le reste, les règles de sécurité, les limites de taux, les contrôles d’autorisation. Le contrôle d’accès basé sur les rôles (RBAC) est géré à ce niveau, de sorte que l’accès est imposé avant que les données ne soient touchées. Cela signifie des systèmes plus sûrs, un audit simplifié et une conformité plus nette.
Il ne s’agit pas d’ajouter des couches, mais d’ajouter de la clarté et du contrôle. Elle est également portable. Parce que nous avons exploité des normes ouvertes comme OpenID Connect et OAuth 2.0, l’ensemble de cette pile reste agnostique par rapport au cloud, sans aucune dépendance à l’égard d’un fournisseur spécifique.
L’architecture de sécurité et d’accès agnostique au cloud garantit la portabilité et la conformité.
La sécurité n’est pas une couche que l’on ajoute après le développement. Elle doit faire partie de l’architecture dès le départ. Dans ce cas, tout est conçu autour de protocoles standardisés et éprouvés, rien de propriétaire, rien qui ne vous enferme dans un seul fournisseur de cloud.
L’authentification de l’utilisateur se fait à l’aide d’OpenID Connect avec une clé de preuve pour l’échange de code (PKCE). Cela fonctionne bien pour les applications modernes à page unique. Pour les communications entre machines, le système s’appuie sur le flux OAuth 2.0 Client Credentials. Les deux méthodes sont standardisées et compatibles avec la plupart des fournisseurs d’identité.
L’autorisation est basée sur les rôles. Chaque appel à l’API vérifie les rôles et les autorisations de l’appelant au moyen d’un modèle RBAC (Role-Based Access Control). Cela garantit que seuls les utilisateurs ou les services explicitement autorisés peuvent accéder aux documents ou aux métadonnées sensibles. Cette structure permet de centraliser la logique au niveau de la couche API, ce qui simplifie la mise en œuvre et l’audit.
Toutes les communications utilisent TLS 1.2 ou une version plus récente, de sorte que les données en transit sont chiffrées par défaut. Au repos, le chiffrement est géré côté serveur pour les métadonnées (dans les bases de données NoSQL) et le contenu (dans le stockage d’objets). Là encore, il n’est pas nécessaire de recourir à des systèmes de gestion de clés propriétaires, mais seulement à des fonctionnalités standard largement prises en charge. Le système est ainsi portable sur AWS, Azure et Google Cloud.
Du point de vue de la conformité, cette architecture remplit les conditions requises : cryptage, contrôle d’accès, auditabilité et traçabilité. Elle fonctionne dans tous les contextes d’entreprise sans implémentation de sécurité personnalisée par fournisseur de cloud.
Une modélisation des données et une indexation efficaces améliorent l’agilité et l’efficacité des requêtes.
Les coûts de stockage augmentent rapidement lorsque vous travaillez avec des millions de documents. Les performances des requêtes commencent également à se dégrader, à moins que vous n’ayez modélisé vos données avec prévoyance. C’est là que l’optimisation du schéma NoSQL a eu un impact important.
Au lieu de stocker des chaînes de caractères complètes telles que « Legal » ou « Onboarding Document » à plusieurs reprises dans chaque enregistrement, nous avons utilisé des identifiants numériques. Chaque identifiant renvoie à une table de catégories centralisée et mise en cache. Cette approche réduit la charge de stockage, mais surtout, elle simplifie les mises à jour. Renommer une catégorie ou ajouter un support multilingue devient une simple mise à jour de la table au lieu de réécrire des millions d’enregistrements.
Les requêtes sont rapides parce que nous avons d’abord réfléchi aux schémas d’accès et conçu les index en fonction de ces schémas. Les clés primaires sont basées sur les identifiants uniques des documents. Les index secondaires sont construits sur l’ID du membre et la catégorie du document pour prendre en charge les recherches les plus courantes, comme « donnez-moi tous les documents juridiques pour ce compte ». Cela a permis d’éliminer le besoin de balayage complet des tables, même à grande échelle.
Nous avons également tiré parti de la capacité de lecture de schéma de NoSQL. Cela signifie que lorsque de nouveaux champs de métadonnées sont ajoutés, il n’est pas nécessaire d’effectuer des migrations de schéma. Vous commencez simplement à inclure le nouveau champ dans les futurs enregistrements. Les mises à jour peuvent ainsi être mises en service en quelques heures, et non en quelques semaines, et il n’y a pas de temps d’arrêt. Ce type d’agilité dans un système documentaire permet aux équipes d’aller de l’avant sans avoir à se heurter à des obstacles liés aux bases de données.
Pour les dirigeants, l’implication est simple : des requêtes plus rapides, une empreinte de stockage plus petite et des cycles de livraison nettement plus courts lors de la mise à jour ou de l’extension des modèles de données pour prendre en charge de nouveaux produits ou des besoins en matière de conformité. Cela favorise la flexibilité de l’entreprise sans imposer de refonte de l’infrastructure ou de coupes budgétaires.
De solides mécanismes de reprise après sinistre garantissent la continuité des activités
Un système de gestion documentaire moderne n’est pas complet sans une stratégie intégrée de reprise après sinistre qui fonctionne réellement quand il le faut. Le rétablissement du service après une panne, qu’il s’agisse d’un bogue du système, d’une automatisation mal configurée ou d’une panne régionale, ne peut pas nécessiter d’intervention manuelle ou de suppositions. Elle doit être automatisée, prévisible et testée.
Du côté des métadonnées, nous utilisons Point-in-Time Recovery (PITR), qui est pris en charge par les principales plateformes NoSQL telles que DynamoDB, Firestore et Cosmos DB. PITR sauvegarde en permanence les opérations d’écriture, ce qui nous permet de revenir sur l’état de notre magasin de métadonnées à n’importe quelle seconde dans une fenêtre prédéfinie, généralement de 7 à 35 jours. Cela nous protège contre les pertes de données dues à des erreurs humaines ou à des problèmes de logique du système.
Pour les fichiers eux-mêmes, la couche de contenu, nous avons mis en œuvre le versionnage et la réplication interrégionale par l’intermédiaire de systèmes de stockage d’objets de commodité. La gestion des versions garantit que si quelqu’un télécharge une nouvelle version d’un fichier ou en supprime une par erreur, les versions antérieures restent accessibles. La réplication interrégionale signifie que chaque document est automatiquement copié dans un emplacement physique distinct. En cas de panne ou d’interruption dans une région, l’accès aux documents reste possible dans la région secondaire.
Cette configuration à deux niveaux, PITR pour les métadonnées structurées et stockage d’objets entièrement répliqués pour le contenu, élimine la plupart des risques opérationnels. Elle est évolutive, nécessite peu de maintenance et ne dépend pas du cloud. L’absence de dépendance à l’égard d’outils ou de plateformes propriétaires signifie que vous pouvez la mettre en œuvre et la maintenir dans différents environnements sans avoir à remanier votre dispositif de reprise après sinistre.
Pour les chefs d’entreprise, l’impact est la résilience opérationnelle. Vous réduisez le risque de temps d’arrêt, vous maintenez l’état de préparation à la réglementation et vous permettez aux équipes de continuer à travailler même en cas de défaillance de l’infrastructure régionale ou d’erreurs internes.
La gestion du cycle de vie par l’archivage sur suppression réduit les coûts et maximise les performances.
Les coûts de stockage n’évoluent pas de manière linéaire, ils augmentent lorsque vous mélangez des données chaudes et froides dans le même environnement au fil du temps. Nous nous sommes attaqués à ce problème dès le début en mettant en œuvre un modèle de cycle de vie d’archivage sur suppression. L’idée de base est la suivante : lorsqu’un document est supprimé, nous ne laissons pas d’indicateur de suppression dans le système primaire. Au lieu de cela, l’enregistrement est entièrement déplacé, les métadonnées vers une table d’archivage et le contenu vers des niveaux de stockage d’archivage tels que Amazon S3 Glacier, Azure Blob Archive ou Google Coldline.
Cette approche permet de conserver l’ensemble des métadonnées actives, seuls les documents actuels restent consultables par le biais de requêtes NoSQL très performantes. Cela se traduit par des temps de réponse plus rapides et une utilisation moindre de la mémoire et du calcul dans les magasins primaires. Cela évite également de payer des coûts élevés pour maintenir des données qui ne sont pas activement utilisées.
Pour le contenu, le stockage à froid est nettement moins cher que le stockage d’objets standard. Ces niveaux de stockage d’archives sont conçus pour la conservation à long terme où l’accès est rare, et tous les principaux fournisseurs de cloud les proposent avec des modèles de tarification similaires. La transition du contenu supprimé vers le stockage à froid après une période de rétention définie entraîne une réduction immédiate et durable des factures de cloud.
Il s’agit d’un processus axé sur les politiques, facilement automatisé à l’aide des règles de cycle de vie fournies par les plateformes cloud. Il est évolutif et ne nécessite qu’une surveillance manuelle minimale une fois qu’il est mis en place.
Le résultat pour l’entreprise est prévisible : la maîtrise des coûts sans compromis sur les performances. Vous maintenez un système rapide et réactif pour les utilisateurs finaux tout en gérant efficacement les besoins de stockage à long terme en arrière-plan. C’est ainsi que vous construisez pour l’échelle sans dépenser trop.
Accepter la cohérence éventuelle comme compromis pour l’évolutivité horizontale
Lorsque vous concevez pour l’échelle, les compromis doivent être intentionnels. L’un des compromis les plus stratégiques que nous ayons faits a été de choisir la cohérence à terme pour la plupart des opérations de lecture au lieu d’appliquer par défaut une cohérence forte et immédiate. Cette décision nous a permis d’obtenir une évolutivité horizontale sans compliquer excessivement l’architecture ni gonfler les coûts opérationnels.
Dans la pratique, cela signifie qu’après l’écriture d’un nouveau document, il peut y avoir un court délai, souvent inférieur à une seconde, avant qu’il ne soit visible dans toutes les opérations de lecture ultérieures. Pour un système de gestion de documents utilisé principalement par des humains, et non par des machines exécutant des transactions synchrones, ce délai est indétectable. L’utilisateur ne pourrait pas le remarquer à moins de le chronométrer spécifiquement.
Pour les cas opérationnels ou marginaux, comme les intégrations ou les flux de travail automatisés, où un comportement strict de lecture après écriture est requis, la plupart des services NoSQL offrent la possibilité d’effectuer des lectures fortement cohérentes. Cette option peut être activée de manière sélective, par requête, afin d’assurer une cohérence immédiate lorsque cela est absolument nécessaire.
Cette flexibilité permet à l’architecture de rester efficace en cas de charge élevée, tout en assurant la précision lorsque le cas d’utilisation l’exige. Il n’est pas nécessaire d’enfermer l’ensemble du système dans le coût et la complexité d’une cohérence universellement forte si 99 % des lectures ne l’exigent pas.
Du point de vue de la direction, cela favorise la croissance sans ingénierie excessive. Vous obtenez la vitesse et l’élasticité avec la prévisibilité, sans accepter de risque réel pour l’utilisateur ou l’entreprise.
L’amélioration des performances et la réduction des coûts valident l’architecture
Un système doit être performant sous pression, sinon l’élégance du schéma n’a pas d’importance. Nous avons testé les chiffres dans des scénarios de trafic réels et les performances ont constamment dépassé les attentes.
Sous une charge soutenue de 4 000 requêtes par minute, le système a maintenu une latence médiane d’environ 200 millisecondes pour les requêtes de métadonnées. Même les 5 % de requêtes les plus lentes sont restées inférieures à 300 millisecondes. Et ce, sans aucune dégradation, sans aucune erreur au niveau du système ou du protocole HTTP, et avec un excellent score Apdex de 0,97.
Ce qui est plus important encore, c’est la manière dont tout cela a pu être mis à l’échelle de manière rentable. Le système a été testé pour gérer 10 millions de documents, chacun d’une taille moyenne d’environ 100 Ko, soit un total d’environ 1 téraoctet de contenu. Les opérations mensuelles comprenaient 20 millions de lectures de métadonnées et 1 million de téléchargements. Sur AWS, Azure et Google Cloud, les coûts mensuels totaux sont restés compris entre 33 et 39 dollars.
Cette tarification inclut les lectures/écritures NoSQL sans serveur, le stockage d’objets durables et le traitement des requêtes, entièrement basé sur l’utilisation. Il n’y a pas de capacité pré-engagée, ni de serveurs inactifs qui consomment de l’argent. Le résultat est un système qui ne se contente pas d’être performant, il évolue en fonction des besoins et se réduit lorsque la demande est plus faible, ce qui permet de conserver des marges intactes.
Pour les dirigeants, cela élimine l’imprévisibilité des dépenses d’infrastructure informatique et montre qu’avec des choix architecturaux intelligents, une performance élevée n’exige pas un coût élevé. C’est à la fois évolutif, stable et efficace.
L’architecture établit un plan réutilisable pour la gestion moderne des documents.
La valeur d’une architecture évolutive augmente de façon exponentielle lorsqu’elle est reproductible. Il ne s’agit pas seulement d’une amélioration ponctuelle des performances, mais d’un modèle réutilisable fondé sur la séparation des responsabilités, un comportement prévisible en matière d’évolutivité, un dispositif de sécurité solide et un fonctionnement rentable.
En divisant les métadonnées et le contenu des fichiers en charges de travail indépendantes, en renforçant la séparation avec une approche API-first et en utilisant des technologies agnostiques au cloud pour le stockage, l’identité et la sécurité, nous avons créé une conception qui fonctionne dans toutes les entreprises, tous les secteurs et toutes les plates-formes. Elle n’est pas liée à AWS, Azure ou Google Cloud. Elle est portable et pragmatique.
La sécurité est assurée par des normes ouvertes. L’autorisation est clairement séparée de la logique de l’application à l’aide du contrôle d’accès basé sur les rôles (RBAC) au niveau de la passerelle API. Le stockage utilise des couches économiquement optimisées avec une gestion automatique du cycle de vie. La reprise après sinistre est intégrée, et non pas ajoutée après coup. L’agilité est intégrée dans le modèle de données à l’aide de schémas en lecture, ce qui permet une itération rapide sans temps d’arrêt.
Chaque élément est conçu pour évoluer indépendamment, horizontalement, de manière prévisible et sans remaniement. Que vous gériez 10 000 documents ou 10 millions, le comportement opérationnel reste cohérent. Les mesures de performance restent fiables, la latence n’augmente pas et le coût de l’infrastructure évolue de manière linéaire en fonction de l’utilisation, et non de la complexité.
Du point de vue de la direction, il s’agit d’un atout stratégique. Vous ne vous contentez pas de résoudre un goulot d’étranglement technique, vous déployez un modèle opérationnel qui permet de réduire les dépenses, de soutenir la croissance et de réduire les frictions de commutation en aval. Ce cadre peut être adopté par de nouvelles équipes de produits, étendu pour traiter d’autres types de documents ou transformé en services autonomes dans des environnements mondiaux.
Pour les organisations qui construisent ou modernisent une infrastructure numérique, c’est le type de système qui permet aux équipes d’ingénieurs de se concentrer sur les résultats des produits tout en maintenant la stabilité à l’échelle. Il fait ce qu’il doit faire, avec clarté, cohérence et efficacité. Et il est prêt à être réutilisé.
Le bilan
Il ne s’agit pas seulement de documents. Il s’agit de la manière dont les systèmes évoluent, dont les équipes progressent plus rapidement et dont les entreprises évitent des remaniements coûteux en cours de route. En séparant les métadonnées du contenu et en appliquant cette séparation par le biais d’API, nous avons créé un cadre rapide, facile à maintenir et prêt à évoluer sans ajouter de complexité.
Tous les éléments de cette architecture ont un objectif clair : accélérer les performances, réduire les coûts, simplifier les opérations et renforcer la sécurité. Elle fonctionne avec tous les fournisseurs de cloud, résiste à la pression et ne vous lie pas à un seul fournisseur.
Pour les décideurs, il s’agit d’un modèle de travail qui montre comment des choix techniques réfléchis ont un impact direct sur les résultats de l’entreprise. Il montre que la modernisation n’est pas forcément synonyme de refonte. Avec la bonne architecture, vous construisez une seule fois, vous évoluez de manière prévisible et vous restez flexible lorsque les priorités changent.
Il s’agit d’une approche conçue pour durer.
