En présentant Active Directory il y a deux ans, Microsoft soulignait certes l’importance d’une réflexion architecturale poussée pour que le service d’annuaire LDAP colle à la réalité organisationnelle de l’entreprise. Sans doute encore trop proche de la théorie, cette approche du service d’annuaire reposait sur l’idée qu’une arborescence complexe, dont les branches représenteraient les subdivisions organisationnelles, pourrait suffire à modéliser l’entreprise et à cartographier les utilisateurs ayant accès à son système d’information. Mais la reconstitution de la chaîne de circulation des données utilisateurs dans une en-treprise n’est simple qu’en théorie.LDAP est aux référentiels d’entreprise ce que les pro-giciels de gestion sont aux données comptables : un outil de normalisation. Il a donc le même effet structurant sur l’entreprise. Toutefois, l’objectif premier d’un service d’annuaire LDAP est de normaliser non pas les données, mais la recherche de celles-ci, et ce, quels que soient les applications ou les systèmes censés y faire appel. Pour y parvenir, il ne suffit pas d’identifier les redondances. Il faut pouvoir modéliser les flots de données, c’est-à-dire déterminer, pour chaque référentiel, qui est habilité à créer ou modifier l’enregistrement, selon quelle méthode et à partir de quelle source (un autre annuaire, par exemple). Non seulement ces procédures restent souvent informelles, car elles ne sont pas toujours critiques pour le métier de l’entreprise, mais toutes ne sont pas reproductibles, ni transmissibles.Ainsi, le répertoire téléphonique est généralement établi par les services généraux, et non par la cellule d’administration LDAP de la direction informatique. Pour autant, les services généraux n’ont pas besoin de connaître en détail la configuration du système de téléphonie IP. La nature de ces obstacles organisationnels suggère d’elle-même la solution : conserver intactes les prérogatives de chacun des ” métiers ” de l’entreprise, et donc compartimenter, voire séparer les annuaires.
L’extensibilité du schéma doit rester limitée
Au demeurant, le protocole LDAP, de par ses limites techniques, ne laisse pas véritablement le choix. Rendue souhaitable pour mieux s’adapter à la réalité organisationnelle de l’entreprise, la segmentation des annuaires LDAP s’impose définitivement dès que l’on songe aux deux fonctions essentielles d’un service d’annuaire : interroger et répliquer les données. Car les performances et les possibilités d’exploitation en production d’un annuaire LDAP dépendent essentiellement de son arborescence.Le schéma LDAP fixe les types de données que contiendra l’annuaire. Il permet de déclarer les catégories d’objets, mais aussi d’en définir les sous-groupes, groupes et unités organisationnelles d’appartenance, c’est-à-dire la structure relationnelle. Une fois conçu, le schéma LDAP peut théoriquement être enrichi d’objets et d’attributs propres à une application. Un serveur de messagerie Exchange 2000, par exemple, ” étend ” le schéma LDAP générique d’Active Directory pour y inclure les objets qui lui sont propres. En théorie, toute application compatible LDAP est censée faire de même, et l’extensibilité est l’un des atouts premiers du modèle LDAP. Héritier du protocole d’annuaires pour opérateurs X.500 (DAP), LDAP n’a cependant pas été véritablement conçu pour cela. Chez les opérateurs, X.500 est certes utilisé pour échanger de gros volumes d’informations, mais sur la base d’un schéma relativement simple, au point de pouvoir être qualifié d’annuaire ” plat “, par opposition aux arborescences théoriques de LDAP. Cette structure permet l’exploitation de requêtes LDAP simples et limite le temps de calcul nécessaire à la résolution des niveaux de regroupement. En entreprise, c’est tout l’inverse. Chaque subdivision de son organisation crée un niveau de complexité supplémentaire qui obscurcit le schéma et fait peser un risque important sur les performances du service d’annuaire. Là encore, la simplicité de l’architecture reste le meilleur moyen d’éviter l’écueil. L’annuaire unique est cette fois bien mort et enterré. Il ne s’agit plus de modéliser l’ensemble de l’organisation, mais simplement ses sous-parties, qui sont à considérer comme autant d’entités distinctes.
L’annuaire à plat : une version simplifiée pour applications
Dans la pratique, cette approche donne naissance à deux types de services d’annuaires, entre lesquels se répartissent aujourd’hui les acteurs du marché (lire tableau ci-contre). D’un côté, les annuaires ” système ” ont pour vocation de modéliser tout ou partie d’un système d’information dans une zone géographique donnée. De l’autre, sont apparus des annuaires dits ” applicatifs “, exclusivement dédiés à lister les utilisateurs d’une application ou d’un portail web. Notons que cette dernière catégorie adopte fréquemment un schéma simplifié, ou ” annuaire plat “, pour en optimiser les performances. De cette façon, les administrateurs du système d’information évitent le risque que le schéma ” système ” ne soit pollué par les extensions d’applications installées ponctuellement, ou qui ne concernent qu’une toute petite partie du système d’information. Une expérience de terrain désormais validée par les éditeurs eux-mêmes. Dans le cadre de son offre .NET, Microsoft compte ainsi proposer une version allégée d’Active Directory, destinée à servir de référentiel isolé pour une application. L’éditeur de Windows aura également revu d’ici là les méthodes de synchronisation autorisant la réplication d’objets individuels, là où il fallait auparavant répliquer l’ensemble du groupe d’appartenance, même si un seul attribut avait été modifié.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
