--- title: "Architecture de l'information" route: "/approche-demarche/architecture-de-l-information" description: "Clarifiez les objets, les flux, les responsabilités et les règles qui structurent l'information avant de choisir ou de faire évoluer les outils." --- # Architecture de l'information Axiome aide les organisations à définir comment elles nomment, relient, partagent et gouvernent leurs informations. Ce travail précède le choix des outils. Il transforme les objets du métier, leurs relations, leurs responsabilités et leur cycle de vie en un modèle compréhensible par les équipes et exploitable par le système d'information. ## Quand l'entreprise n'est pas d'accord avec elle-même Un dirigeant ne pense pas en taxonomie. Il pense produits, clients, commandes, fournisseurs et décisions à prendre. Le désordre apparaît lorsque le commerce, la comptabilité et la logistique n'utilisent pas la même définition d'un client actif, d'un produit terminé ou d'une commande clôturée. Dans ce contexte, aucune plateforme ne peut produire seule une vue cohérente. Une IA peut rapprocher des formulations ou retrouver des documents, mais elle ne doit pas décider quelle définition métier fait autorité. Cette décision appartient à l'organisation. ## Partir des objets, des flux et des responsabilités Nous commençons par écouter les métiers et observer leurs supports : documents, tableaux, applications, nomenclatures, circuits de validation, données et exceptions. Les ateliers cherchent à rendre explicites : - les objets métier et le vocabulaire utilisé pour les décrire - les relations entre contenus, acteurs, processus et systèmes - les statuts, transitions et cycles de vie - les personnes qui produisent, valident, publient ou archivent - les sources qui font autorité et celles qui les complètent - les règles de visibilité, de confidentialité et de conservation Le résultat n'est pas un classement générique appliqué à l'entreprise. C'est une représentation partagée de son fonctionnement, suffisamment précise pour guider une architecture, un backlog, une migration ou un corpus de connaissances. ## Donner une place à chaque niveau de maturité Une information personnelle en préparation ne porte pas les mêmes exigences qu'un contenu de travail collectif ou qu'une référence publiée pour toute l'organisation. Son emplacement, son propriétaire, ses droits et ses règles de maintenance doivent évoluer avec sa maturité. Dans Microsoft 365, un repère utile consiste à distinguer : - OneDrive pour la préparation personnelle - Teams pour la collaboration active d'une équipe - SharePoint pour la capitalisation, la publication et le patrimoine commun Ce modèle n'est ni une règle universelle ni une obligation technologique. Le même raisonnement s'applique à une application métier, un ERP, une base de données ou un autre environnement collaboratif : qui porte l'information, quand change-t-elle de statut et à quel moment devient-elle une référence pour d'autres personnes ? ## Gouverner sans figer Une architecture utile doit pouvoir évoluer sans revenir au désordre initial. Nous organisons quatre responsabilités complémentaires : - **Connaître.** Identifier les types d'informations, leurs usages et leurs circuits - **Gouverner.** Définir les propriétaires, les règles de création, les droits et le cycle de vie - **Maintenir.** Organiser les versions, la qualité, l'archivage et le traitement des doublons - **Protéger.** Maîtriser les accès, les partages externes et les niveaux de confidentialité Un audit ponctuel ne suffit pas. Les règles doivent pouvoir être appliquées dans le travail quotidien, suivies et ajustées lorsque les métiers, les outils ou les obligations changent. ## Modéliser le sens et traiter la qualité des données Le nettoyage d'une donnée et la modélisation du métier répondent à deux problèmes différents. Corriger un format, supprimer un doublon ou compléter une valeur améliore la qualité technique. Définir ce qu'est un client actif, relier une commande à son contrat ou distinguer une règle générale d'une exception donne du sens à cette donnée. Les deux travaux peuvent être nécessaires. La qualité technique ne compense pas une définition ambiguë, et un modèle pertinent reste difficile à exploiter si les données qui l'alimentent sont incomplètes ou incohérentes. ## Préparer les équipes, les systèmes et l'IA Une architecture claire aide les utilisateurs à retrouver une information, à comprendre son statut et à savoir qui peut la modifier. Elle fournit aussi aux systèmes de recherche et aux usages IA des repères importants : version validée, date, portée, propriétaire, niveau d'accès et relation avec les autres sources. Elle ne rend pas automatiquement une réponse IA fiable. Le choix du cas d'usage, la préparation du corpus, les contrôles d'accès, la qualité des sources et la validation humaine restent nécessaires. L'architecture réduit l'ambiguïté et rend ces contrôles possibles. ## Notre rôle Nous animons les ateliers, formalisons les modèles, testons leur compréhension avec les équipes et les transformons en décisions exploitables. Selon le périmètre, les livrables peuvent comprendre : - un vocabulaire et un modèle des objets métier - une cartographie des flux et des responsabilités - des cycles de vie et règles de gouvernance - une architecture cible - des principes de classement, de recherche et de sécurité - un backlog ou une trajectoire de transformation Nous intervenons lors d'un cadrage, d'une refonte, d'une migration, d'un projet Microsoft 365, d'une application métier ou de la construction d'un corpus pour l'IA. [Voir comment le cadrage transforme ce travail en livrable](/offres/projets-m365#cadrage-et-architecture). ## Clarifions le langage commun de votre organisation Le point de départ peut être un projet déjà identifié, une recherche qui ne fonctionne plus, des responsabilités floues ou un usage IA qui manque de sources fiables. [Décrivez-nous votre contexte](/contact).