Les Impôts sont plus réputés pour "  assaisonner  " les entreprises que pour les soigner. La Direction générale des impôts (DGI) a néanmoins fait le bonheur de l'une d'entre elles en 2001. Elle a retenu Novell pour l'un des plus gros projets mondiaux d'annuaire. Le montant du contrat - près de 10 millions d'euros -, reflète l'ampleur du chantier. D'ici à trois ou quatre ans, l'administration fiscale prévoit de stocker quelque 35 millions d'entrées dans un annuaire LDAP (Lightweight Directory Access Protocol) . L'ensemble des 31 millions de foyers fiscaux et des entreprises privées (2,5 millions) sera répertorié. A la clé, la promesse de relations simplifiées avec les services des Impôts.

L'alimentation de l'annuaire s'effectuera toutefois progressivement. En attendant, celui-ci sert d'abord à assurer les besoins internes de la DGI ainsi qu'à fluidifier ses relations avec ses partenaires privilégiés - les notaires par exemple. Il faut voir l'annuaire comme la première brique d'un vaste projet de refonte du système d'information de la DGI, dont les deux mots d'ordre sont décloisonnement des applications et ouverture sur internet. Cette première phase est aujourd'hui bien avancée. L'ensemble des employés et des partenaires - soit une population d'environ deux cent mille personnes - est aujourd'hui référencé dans eDirectory. "  Parmi les administrations, la DGI fait figure de précurseur dans le déploiement d'annuaires  ", se félicite Jean Nizoux, l'un des responsables du projet côté Administration.

Avant d'en arriver là, la Direction générale des impôts a dû sélectionner, parmi les serveurs d'annuaires compatibles avec le protocole d'accès LDAP version 3, un modèle capable de tenir la charge. Ce dernier point - critique - est difficile à évaluer. En effet, tous les spécialistes - Critical Path, iPlanet et autres Novell - clament que leurs logiciels encaissent, sans coup férir, des milliers de requêtes simultanées et qu'ils stockent plusieurs dizaines de millions d'entrées. Mais on sait aussi que, en pratique, des problèmes de montée en charge surviennent parfois avant le million d'entrées. Pour étayer son choix, les Impôts ont sollicité les grands cabinets de conseil. Ils ont aussi procédé à leurs propres tests de montée en charge sur les six offres qui restaient en lice après une première présélection. "  Nous avons saturé d'autres serveurs avant l'annuaire  ", se rappelle Christian Longuere, commercial en charge du compte DGI chez Novell, l'un des fournisseurs figurant sur la liste restreinte. Les performances et la gestion de la redondance grâce à une architecture associant plusieurs annuaires maîtres offertes par l'éditeur ont contribué à faire pencher la balance en sa faveur. L'année dernière, l'annuaire d'iPlanet, le principal concurrent de Novell, ne communiquait pas en mode maître-maître, mais seulement en mode maître-esclave. Les équipes de Novell ont aussi fait valoir leur expérience dans les projets d'annuaires. L'appel d'offres stipulait que le fournisseur devrait préciser quelles études en matière d'architecture et de design d'annuaires seraient nécessaires. "  Nous n'avons pas sous-estimé cette étape  ", indique Christian Longuere - laissant ainsi entendre que ses concurrents n'avaient peut-être pas apporté le même soin à cette phase cruciale. La DGI a, pour sa part, été sensible à la capacité de modifier les schémas de l'annuaire. Earl Perkins, analyste spécialisé dans l'architecture au Meta Group, approuve et tempère : "  Novell, présent depuis plus longtemps que d'autres sur ce marché, bénéficie d'une véritable expérience. Cela dit, la modification du schéma d'un annuaire est loin d'être une opération triviale.  "

Un dernier critère était primordial dans le choix de la DGI : le prix. L'Administration ne laisse toutefois presque rien filtrer sur le sujet. L'éditeur se montre aussi très discret sur la répartition entre ses différents produits (eDirectory, iChain et DirXML), ainsi que sur la part du service dans le budget global du projet. On sait seulement que Novell n'a pas fait de fleur tarifaire à son client avec des prix similaires à ceux de ses concurrents. Plus globalement, la tarification au nombre d'entrées prête le flanc à la critique. La DGI, comme d'autres organisations, accepte difficilement de voir le prix de licence grimper en même temps que le nombre d'entrées de l'annuaire, alors que, sur le plan technique, rien ne change. Pour Jean Nizoux, la négociation sur les prix avec l'éditeur a d'ailleurs été avant tout "  un rapport de forces  ". De la conception au déploiement, il y a cependant tout un monde. La DGI a pu le vérifier. Sur le papier, l'annuaire communique d'un trait avec l'ensemble des applications, mais la réalité est plus rebelle. "  L'interfaçage avec la télédéclaration - aujourd'hui opérationnelle - s'est révéle difficile  ", reconnaît Jean Nizoux. Plus que l'aspect logique, avec le rapprochement des annuaires provenant de différentes applications au sein d'un référentiel central, c'est la mise en relation même des applications qui a posé un problème. Il faut dire que l'architecture du projet de la DGI est ambitieuse. La seule alimentation de l'annuaire fait intervenir de multiples applications.

Une base de données Oracle communique avec eDirectory via un connecteur DirXML. Cette même base est reliée aux applications de gestion du personnel, à celles de la messagerie Domino, etc. L'alimentation de l'annuaire s'effectue de façon quasi automatique, pratiquement sans aucune saisie en direct. De son côté, eDirectory devient une source de données pour Ader, le projet de méta-annuaire commun à toutes les administrations. Voilà pour la seule partie alimentation. Mais l'annuaire est aussi connecté à l'ensemble des applications reliées à l'intranet ou sur internet. Il s'inscrit, en effet, dans une architecture à clés publiques et contient les certificats. Il stocke également les habilitations qui seront utilisées par les applications pour mettre en oeuvre les règles de sécurité. Cette refonte du système d'information crée une interdépendance entre les applications, à l'origine d'un certain nombre de surprises. "  Il faut être capable d'identifier la brique défaillante  ", explique Jean Nizoux. Cela passe par l'ajout d'une nouvelle couche logicielle et le recours aux outils de test de Compuware.