 |
 |
 |
|
LDAP
|
|
|
|
|
Démarche LDAP
|
|
|
META ANNUAIRE
|
|
|
|
|
|
|
|
|
 |
|
 |
|
|
|
|
|
|
|
 |
|
Notre démarche de mise en place d'annuaire LDAP
|
| Cette démarche LDAP est le fruits de 10 ans d'expériences, à travers de nombreux projets d'annuaire d'envergure. |
 |
| La démarche LDAP comporte une partie transversale pour le pilotage, et une partie plus séquentielle pour les différentes étapes du projet : |
|
1.1. Comité de pilotage du projet LDAP
|
Nous participerons au comité de pilotage qui sera constitué, entre autres, de différents intervenants chez le client : utilisateurs, HR, gestionnaires de données actuels, chef de projet, etc.
Ce comité aura comme mission de
- confronter les besoins de chacun
- effectuer des choix techniques
- coordonner les actions
- surveiller l'avancement du projet
- valider les réalisations
Ce comité se réunira régulièrement, à raison d'une demi-journée par semaine. Si on suppose qu'il y a au moins un représentant par source de données, le comité de pilotage impliquerait un bon nombre de personnes. Ceci constitue les plus grosses charges pour le client.
Les étapes de mise en place de l'annuaire LDAP peuvent être groupées en cinq parties : étude et conception générale, prototypage, réalisation, intégration et mise en production. |
|
1.2. Etude et Conception Générale de l'Annuaire LDAP
|
1.2.1. Etude de l'existant et de l'environnement.
|
Un annuaire LDAP étant le pivot central des informations disponibles dans une entreprise, sa mise en place nécessite la participation d'acteurs de domaines très larges : utilisateurs finaux, ressources humaines, communication, informatique, etc.
Sauf dans un cas de création, une entreprise ou une administration possède en général déjà un ou plusieurs annuaires (LDAP ou autres), voire quelques centaines d'annuaires, en plus des bases de données de différentes origines.
Ces systèmes ont nécessité beaucoup d'investissements, ils sont utilisés dans la vie de tous les jours de l'entreprise. Des procédures bien établies sont appliquées quotidiennement pour maintenir ces systèmes, les gestionnaires sont bien formés et accomplissent leur tâche avec efficacité et précision.
Mais ces systèmes sont bien souvent déconnectés les uns des autres, créant des difficultés de communication entre services, nécessitant des mises à jour répétées des mêmes informations dans plusieurs systèmes, générant ainsi des incohérences et des problèmes de maintenance.
Un projet d'Annuaire LDAP global est confronté à la fois aux problèmes techniques inhérents aux systèmes hétérogènes, et aux problèmes organisationnels et politiques liés au mode de fonctionnement actuel de l'entreprise. |
|
Un tel projet constitue aussi une occasion précieuse de bilan global sur le système d'information, et une réflexion à plus long terme sur l'organisation de l'entreprise.
En fonction de la situation de l'entreprise, un Annuaire LDAP peut remplacer un système actuel, mais dans la majorité des cas, il doit s'intégrer dans un contexte d'exploitation et jouer un rôle de fédération, au lieu de bouleverser un paysage existant. |
|
1.2.2. Définition du besoin du projet LDAP
|
L'environnement du projet bien cerné, il faut maintenant définir clairement l'objectif du projet, les populations d'utilisateurs visées, les fonctionnalités, ses relations avec les autres systèmes, etc.
Par type d'utilisation, on peut identifier des applications différentes qui pourront être construites au-dessus de l'annuaire LDAP.
Les relations avec d'autres systèmes sont bien définies. Les rôles respectifs sont exprimés, qui est maître ? Sur quel type de données ?
Les rôles peuvent évoluer : certains systèmes céderont progressivement leur place au nouveau système.
Comment synchroniser toutes ces données ?
Par synchronisation en temps réel ou en différé ?
Comment le nouveau système va être géré ?
Quel impact sur sa mise en production ?
Un cahier des charges est produit décrivant tous les besoins et contraintes. |
|
1.2.3. Définition du schéma LDAP
|
La définition de schéma est essentielle dans un projet d'annuaire LDAP. Tout changement ultérieur du schéma a un impact sur les applications clientes et sur l'interopérabilité avec d'autres annuaires.
Forts d'expériences accumulées dans des projets d'envergures, notamment pour le Ministère des Affaires Etrangères, Ministère de l'emploi et de la solidarité, EDF-GDF, la Mairie de Paris, etc., nous sommes familiers aux spécificités des schémas concernant les grandes entreprises.
Un schéma comprend la définition de l'arborescence, des classes d'objets, des attributs (avec leur syntaxe), les contraintes sur la structure, sur les attributs utilisables, etc.
La définition de schéma prend en compte beaucoup de considérations :
- Respect des recommandations de la norme : ce qui améliore l'interopérabilité entre tout autre Annuaire LDAP dans le futur. Ces recommandations portent à la fois sur la structure de l'arbre (DIT : Directory Information Tree), sur les classes d'objets prédéfinies et sur les attributs prédéfinis. Si les classes ou attributs prédéfinis ne sont pas suffisants, il faut, si possible, étendre le schéma par héritage.
- Respect d'un schéma minimum commun à l'ensemble des organisations qui souhaitent constituer un Annuaire LDAP global, dans le cas des administrations par exemple, un socle de données commun et les recommandations de l'Annuaire interministériel. Ce qui assure une communication sans conflit (ou avec moins de conflit) entre les annuaires LDAP à l'intérieur et à l'extérieur d'un ministère.
- Identification des objets et des informations associées qui seront manipulés par l'Annuaire LDAP : c'est une activité de modélisation de données, similaire à celle d'une base de donnée classique. Cette modélisation est possible seulement si une étude de l'existant a été bien menée, les sources de données bien identifiées et décortiquées.
- Structure organisationnelle : dans un contexte où la structure organisationnelle elle-même est une information importante, l'arbre de l'annuaire LDAP (DIT) doit pouvoir refléter fidèlement cette structuration, sans qu'il soit obligatoirement isomorphe.
- Répartition géographique des sites : les sociétés possèdent souvent des organismes répartis géographiquement, sur le plan national voire international. Si la notion du site est prédominante, on peut utiliser une arborescence parallèle, des pointeurs permettent de relier les sites avec les unités, les personnes. Sinon, les sites peuvent être gérés simplement par des attributs, dans ce cas, nous les indexons pour raccourcir les temps de recherche qui fait intervenir des critères géographiques (pays, région, département, etc..).
- Utilisation de l'Annuaire LDAP: par souci de performance ou de sécurité, on peut prendre des choix qui favorisent les utilisations les plus courantes de l'annuaire LDAP.
Un exemple est l'emplacement des personnes dans la hiérarchie : si beaucoup de mouvements sont effectués entre services, il serait plus judicieux de regrouper les personnes au niveau supérieur, pour qu'une mutation ne nécessite qu'un changement de pointeur, ce qui est beaucoup plus léger et sécurisant que de déplacer l'entrée de la personne dans la hiérarchie.
Un autre exemple est le changement de structure : il faut minimiser les liens qui doivent suivre un déplacement d'un sous arbre. Nous avons déjà développé cette fonctionnalité avec une opération en trois cliques de souris : copier (le sous arbre), coller (dans l'unité cible, mise à jour des liens), supprimer (l'ancien sous-arbre).
- Reprise de l'existant : la réussite d'un Annuaire LDAP passe souvent par une transition douce de l'existant vers le nouveau système, il faut donc minimiser l'impact sur l'utilisation courante des informations. On s'attend à retrouver au moins les mêmes informations sous les formes similaires, ce qui implique un respect des formats des informations existantes. Il faut donc faire en sorte que ces critères soient satisfaits tout en se conformant à la nouvelle norme. Les aspects des données tels que multi ou mono valué, longueur, etc. sont souvent dictés par l'existant.
- Langues : la gestion des langues dans les données mêmes peut se faire à l'aide 1) des nouveaux attributs pour chaque langue, 2) des valeurs distinctes des attributs existants, 3) d'une incorporation dans une même valeur avec une syntaxe appropriée.
La première solution est la moins complexe, mais elle est la moins performante, elle demande également une synchronisation plus forte entre les attributs : quand on en modifie un, il ne faut pas oublier les autres.
La deuxième solution est plus légère, mais l'ordre des valeurs dans un Annuaire LDAP n'étant pas fixe, il faut introduire des indicateurs sur la langue utilisée pour chaque valeur, c'est l'option choisie par LDAPv3, avec l'introduction d'un sous type d'attribut.
La troisième solution est la plus concise et performante, car par la syntaxe on connaît la langue, et du fait que toutes langues sont disponibles dans une même valeur, on récupère les informations avec le moins de requêtes, l'inconvénient peut être la taille totale de la valeur et une syntaxe spécifique inconnue d'autres systèmes. - Fonctionnalité spécifique : par exemple la question de l'ordre protocolaire : nous avons déjà traité ce problème dans d'autres annuaires LDAP à la fois pour les services du même niveau, pour les fonctions et pour les personnes occupant une même fonction. Cet ordre est géré par un attribut spécifique et modifiable par une interface Web de mise à jour.
- Gestion applicative des droits : les droits d'accès dans un annuaire LDAP sont généralement gérés par les ACLs natifs de l'annuaire LDAP, mais ces derniers ne sont modifiables que par le gestionnaire de l'annuaire LDAP. Pourtant, certaines fonctionnalités nécessitent la modification des droits par un administrateur de données ayant moins de pouvoir, ou par l'utilisateur lui-même.
C'est le cas si une personne ne souhaite pas voir s'afficher sa photo sur l'interface de consultation, la personne modifierait elle-même un attribut spécialement prévu pour cet effet, moyennant une authentification par mot de passe (par exemple).
Un mécanisme similaire peut être utilisé pour gérer les listes rouges ou oranges.
Néanmoins, il faut être conscient que ce type de protection n'est pas fiable, car un accès direct à l'annuaire LDAP sans passer par l'applicatif en question verra l'information quand même.
Pour éviter ce problème, on peut utiliser une procédure automatique exécutée avec le droit du gestionnaire qui examine les attributs positionnés par l'utilisateur pour mettre en place les ACLs appropriés, ce qui veut dire qu'une modification de l'utilisateur ne sera effective qu'après le passage de cette procédure périodique. - Héritage des attributs : cet héritage peut se faire en utilisant soit les attributs collectifs aux niveaux supérieurs, soit une recherche en temps réel de l'information manquante en remontant les niveaux.
- Réplication : l'unité de réplication étant un sous arbre, il faut bien structurer le DIT pour ne répliquer que ce dont on a besoin.
- Distribution : dans le cas ou un annuaire LDAP est géré par plusieurs serveurs, des domaines d'autorité doivent être définis.
- Administration : un administrateur peut gérer un domaine d'autorité représenté par un sous arbre, il faut aussi penser dès le départ à la répartition des responsabilités et la traduire dans le schéma.
- Prise en compte d'autres applicatifs : d'autres applicatifs peuvent s'appuyer sur le même annuaire LDAP, notamment les messageries, les applications de groupware ou de workflow. Ces applications exigent souvent la présence des classes d'objet et des attributs spécifiques dans le schéma. On peut citer comme exemple Suitespot de Netscape, tous les serveurs du package s'appuient sur le Directory Serveur, et chacun s'attend à trouver dans l'annuaire LDAP les classes d'objets dont il a besoin pour son fonctionnement.
Un document de schéma d'annuaire LDAP sera produit. |
|
1.2.4. Choix de l'architecture et des produits LDAP
|
Sur la base de l'exigence du besoin exprimé et le schéma défini, on peut choisir l'architecture générale du système.
Cette architecture doit répondre aux besoins d'applicatifs, d'intégration avec d'autres systèmes, de performance, d'évolutivité, etc..
On décide comment les annuaires LDAP vont être répartis, les relations entre eux, qui gère quel branche. Dans le cas de réplication, qui est " maître ", qui est " esclave ", sachant que les modifications ne peuvent se faire que sur le maître.
Dans le cas d'un Annuaire LDAP distribué, l'architecture doit permettre l'interconnexion de tous les Annuaires LDAP et leur réplication.
La conformité du produit avec les standards : par exemple, dans la version 3.1 de Netscape Directory Server, le mécanisme des alias n'est pas encore implémenté, si l'utilisation des alias est impérative pour le projet, on sera contraint de choisir un autre produit.
Les aspects de sécurité doivent aussi être pris en compte : contrôle d'accès, filtrage, firewall, etc.
Nous disposons à cette étape des principaux éléments pour choisir les produits. Des travaux d'évaluation peuvent être menés pour déterminer si un produit satisfait tous les critères du cahier des charges.
La description de l'architecture sera une partie du document du schéma d'annuaire LDAP. |
|
1.2.5. Plan de gestion et d'accès aux données LDAP
|
Il s'agit de l'élément central de l'annuaire LDAP.
Nous entendons par " Plan de gestion et d'accès aux données " la formalisation de l'étude de l'existant en terme de sources de données, les rapports entre elles, l'articulation en terme de synchronisation, les procédures administratives et techniques, la détermination de responsabilité ainsi qu'un plan de contrôle d'accès.
Les données disponibles ont été identifiées lors de l'étude de l'existant, mais il faut prendre en compte les sources de données potentielles ou à venir.
Il faut ensuite identifier les priorités des sources de données les unes par rapport aux autres. Par exemple, la base des ressources humaines a autorité sur les noms, les affectations, les numéros de matricule, etc., par contre, elle n'est souvent pas fiable pour les numéros de téléphone, le numéro de bureau, etc.
A partir de ces priorités, nous concevons des procédures de synchronisation qui assurent la qualité maximum des données dans l'annuaire LDAP. Ces procédures définissent dans quel ordre, avec quel moyen les différentes sources vont alimenter quel type d'information dans l'annuaire LDAP (en temps réel, en différé ou en interactif).
Par exemple, la base RH sera synchronisée en différentiel tous les mois par une procédure automatique, elle ne met à jour les attributs téléphone et télécopie que s'ils ne sont pas encore renseignés.
Les administrateurs des sites utilisent la base téléphonique pour initialiser l'annuaire LDAP, ce qui écrase tous les numéros éventuellement déjà présents, puis ces informations seront gérées par une interface Web qui aura la priorité sur toute autre source, etc.
Ou bien si on possède un autocommutateur capable d'exporter chaque modification, on décide que l'autocommutateur sera couplé en temps réel avec l'annuaire LDAP.
Tout cela nous conduit à la définition des procédures administratives et techniques, qui se traduisent par des règles de gestion et des outils informatiques.
Les responsabilités sont déterminées : qui gérera quoi ?
Découlant de ces responsabilités, les droits d'accès sont aussi établis.
La détermination des profils utilisateurs, ou la gestion des groupes d'utilisateurs etc., s'inscrivent dans ce plan-là.
La gestion des points d'accès ou les types d'authentification (mot de passe, certificat, accès anonyme) peuvent aussi être pris en compte dans ce plan.
Pendant la première période du projet, l'essentielle du travail du comité de pilotage sera la définition de ce plan de gestion et d'accès aux données.
Tous les problèmes (ou presque) organisationnels et politiques doivent être résolus.
Un document de spécification de synchronisation de données sera produit.
Le cahier de recette de synchronisation de données sera rédigé par le client.
Cette étape demande beaucoup de discussions avec les différents intervenants du client.
Globalement, les charges pour le client se répartissent plus en début et à la fin du projet. Si des décisions se font à un rythme lent ou les données ne sont pas disponibles à temps (ce qui arrive assez souvent), le planning global risquera d'être décalé. |
|
1.3. Prototypage de l'Annuaire LDAP
|
Cette partie peut être plus ou moins longue.
Elle peut être un projet en soi si :
- le besoin n'est pas complètement exprimé,
- l'environnement est complexe,
- les applications sont nombreuses,
- etc.
De l'autre côté, dans un projet où l'objectif est bien défini, cette partie peut être presque diluée dans la partie réalisation qui suit. |
|
1.3.1. Reprise des données existantes dans l'annuaire LDAP
|
Le schéma d'Annuaire LDAP nous permet de connaître de façon exacte le " format " des données dans l'annuaire LDAP, ainsi nous pouvons commencer à convertir les données existantes pour alimenter le nouvel annuaire LDAP.
Bien souvent, au stade du prototypage, toutes les données ne sont pas encore disponibles, on n'utilise donc qu'une partie représentative des données. |
|
1.3.2. Design de l'interface Web de gestion de contenu de l'annuaire LDAP
|
On propose une conception graphique qui doit respecter, si disponible, la charte graphique existante de l'entreprise.
Ce respect est rendu possible par l'utilisation de notre passerelle.
Le design de l'interface nécessite la connaissance du schéma d'Annuaire LDAP notamment pour l'organisation de la structure, la nature de chaque information, etc.
Par exemple, si un attribut est multi-valué, il faut prévoir l'affichage d'une liste, si un attribut est booléen, on peut prévoir une case à cocher, etc.. |
|
1.3.3. Prototypage de l'annuaire LDAP
|
Nous faisons la distinction entre une maquette et un prototype.
Une maquette a pour objectif de démontrer ou évaluer une solution technique, ou une fonctionnalité particulière. Elle vise un objectif immédiat, et est réalisée rapidement, sans souci de qualité, ni préoccupation du contexte réel de fonctionnement. Bien souvent, on simule des comportements du système (on " triche ").
Utiliser une maquette comme une base de développement pour un vrai projet coûterait, faute de qualité intrinsèque suffisante, plus chère que de tout re-développer.
Une maquette est donc " jetable ". Elle est utilisée souvent dans les premières études de faisabilité ou d'évaluation des produits.
Le prototype, quant à lui, est une première version du futur produit. Il est placé dans le processus du développement réel, avec toutes les contraintes qui s'imposent : qualité, règles de programmation, réutilisabilité, extensibilité, etc..
Comme la maquette, il a un rôle de démonstration et de validation, il permet de détecter d'éventuels problèmes dans la conception très tôt dans le processus de développement.
Le prototype contient en général seulement les fonctionnalités essentielles du produit : synchronisation avec quelques sources de données, une interface utilisateur de consultation ou de mise à jour limitée. |
|
1.3.4. Validation du Prototype LDAP
|
Un prototype est un outil de validation, la détection de tout problème nous permet de réviser les choix effectués dans les étapes précédentes et de trouver des solutions alternatives.
Si le prototype est jugé concluant, le projet " grandeur nature " peut être lancé, dans ce cas, il y a en général une consultation d'envergure auprès des utilisateurs et un recensement exhaustif des sources de données.
Nous revenons ainsi à la première étape de la démarche, avec une nouvelle étude de l'existant, reformulation des besoins, révision de l'architecture.
Un cahier des charges définitif va être rédigé.
A l'issue du prototypage, un document de spécification de l'interface Web sera produit.
Le cahier de recette d'interface Web sera aussi rédigé à ce moment-là.
Les autres documents des étapes précédentes seront révisés en fonction du retour du prototype : schéma, spécification et cahier de recette pour la synchronisation des données.
Une grande partie du guide d'administrateur et du guide utilisateur de l'interface Web seront réalisée (sous forme d'aide en ligne). Ces guides seront centrés "tâches", c'est à dire ce que l'utilisateur veut faire, et non pas ce que l'interface peut faire.
La réalisation de ces guides très en amont dans le processus de développement est importante, car la rédaction de ces guides permet de se rendre compte de l'ergonomie de l'interface : une fonctionnalité difficile à expliquer décèle un problème de conception. Plus tôt ces problèmes seront détectés, plus facile sera la correction.
Puis on passe à la partie réalisation. |
|
1.4. Réalisation de l'Annuaire LDAP
|
Cette partie est le corps du développement de l'annuaire LDAP. On y réalise toutes les fonctionnalités retenues dans le cahier des charges.
Ce développement est basé sur le prototype qui a fait l'objet d'une validation.
Il a pour objectif de concrétiser les besoins applicatifs et le plan de gestion et d'accès aux données. Ce qui se traduit par trois activités : outils de synchronisation des données, développement des interfaces utilisateur et paramétrage de l'annuaire LDAP. |
|
1.4.1. Outils de synchronisation des données de l'annuaire LDAP
|
Synchronisation veut dire pérennité de l'annuaire LDAP.
Un Annuaire LDAP ne vit que s'il est mis à jour régulièrement.
Dans cette étape, nous réalisons tous les outils nécessaires à la synchronisation des données, identifiés dans le plan de gestion des données : - chargement des données issues d'autres systèmes.
- extraction des données pour alimenter d'autres systèmes
- mise à jour régulière, globale ou différentielle, en temps réel ou en différé.
|
|
1.4.2. Interface utilisateur de l'Annuaire LDAP
|
Il s'agit plus généralement des applications au-dessus de l'annuaire LDAP.
Il peut s'agir d'une ou plusieurs interface(s) de consultation et/ou de mise à jour.
Nous développons essentiellement des applications Intranet en utilisant les technologies du Web, grâce à notre passerelle HTTP-LDAP WXD.
Le développement d'une telle application nécessite une double compétence : connaissance de l'Annuaire LDAP et connaissance de la création de sites Web.
Notre passerelle a l'avantage de masquer toute la complexité des requêtes vers l'annuaire LDAP, un développeur Web peut l'utiliser en n'ayant qu'une connaissance conceptuelle des données : arborescence, objet, attribut et valeur, plus les " tags " de notre passerelle qui suivent les mêmes principes que le langage HTML. |
|
1.4.3. Paramétrage de l'Annuaire LDAP
|
| Dans le paramétrage, nous incluons la mise en place des contrôles d'accès, la configuration des annuaires LDAP pour la distribution, la réplication, etc.. Ce sont des actions d'administration des annuaires LDAP. |
|
1.5. Intégration de l'Annuaire LDAP
|
1.5.1. Intégration LDAP
|
Nous avons réalisé tous les modules de notre annuaire LDAP, l'intégration consiste à assembler toutes les pièces d'un puzzle, et à vérifier l'interaction entre les éléments. (En général, une partie d'intégration a déjà été effectuée dans la réalisation de chaque module).
On s'assure que les différentes synchronisations des sources de données sont cohérentes, fiables et opérationnelles.
Entre la synchronisation en masse de données et l'interface Web, on vérifiera si les priorités sont bien gérées.
On mesure aussi l'impact de la répartition des serveurs sur la mise à jour.
Les contrôles d'accès applicatifs et ACLs natifs dans l'annuaire LDAP doivent fonctionner de concerte.
Nous développons également les contrôles d'intégrité des données dans ce cadre là.
Bref, l'intégration assure que le système dans son ensemble fonctionne comme prévu.
Les documents de réalisation (synchronisation et interface Web) et le guide d'administration de l'annuaire LDAP et de synchronisation seront produits.
Une révision de l'ensemble de document sera effectuée. |
|
1.5.2. Mise en place des procédures de gestion de l'annuaire LDAP
|
Les procédures de gestion définies dans le plan de gestion des données sont mises en place, avec nomination des administrateurs, publications des règles de gestion, etc.
Cette activité est en principe assurée par le client. |
|
1.5.3. Formation LDAP
|
Dans cette partie du projet, nous formons les administrateurs de données de l'Annuaire LDAP pour qu'ils puissent maintenir le système dans le futur.
Il y a en général aussi un transfert de compétence plus orienté système, destiné aux informaticiens qui seront chargés de l'exploitation au sens informatique.
Nous formons également les utilisateurs finaux, si l'application n'est pas triviale à utiliser. |
|
1.5.4. Déploiement partiel de l'annuaire LDAP
|
Il est toujours prudent d'ouvrir le service pour une partie des clients potentiels pendant une période, afin de tester le système dans son utilisation réelle.
Si d'éventuels problèmes sont découverts, ils sont corrigés sans impact sur tout le public.
C'est pendant cette phase que les administrateurs se familiarisent avec le nouveau système. |
|
1.5.5. Test de performance de l'annuaire LDAP
|
Le déploiement partiel est aussi l'occasion d'optimiser la performance globale du système, par des réglages logiciels ou matériels.
Ces tests seront faits en commun avec le client. |
|
1.5.6. Recette et livraison de l'annuaire LDAP
|
Il peut y avoir une validation séparée pour chaque activité et une validation globale. Cela correspond à la livraison et la recette du système.
La recette se fera conformément aux cahiers des recettes pré-établis.
Comme pour toute recette, les anomalies constatées sont corrigées avant l'acceptation par le client du produit. |
|
1.6. Mise en production de l'annuaire LDAP
|
1.6.1. Déploiement général et Plan média pour l'annuaire LDAP
|
| A ce stade, nous sommes prêts à lancer le système. Un plan média permettra de le faire connaître auprès des utilisateurs. |
|
1.6.2. Exploitation et Maintenance de l'annuaire LDAP
|
Nous entrons dans la phase d'exploitation du système. Les administrateurs assurent leurs responsabilités quotidiennes, les procédures de mise à jour sont appliquées, l'Annuaire LDAP est maintenu en fonction.
Les demandes de nouvelles fonctionnalités peuvent apparaître, elles seront ajoutées au fur et à mesure. Les fonctionnalités existantes peuvent devenir obsolètes ou mériter d'être adaptées aux changements des besoins. C'est ce qu'on appelle la maintenance évolutive.
Bien entendu, il peut aussi subsister des problèmes de fonctionnement, leur correction est comprise dans la maintenance corrective.
La mise en production est assurée par le client, nous pouvons proposer un accompagnement ou une assistance technique en option. |
|
A voir:
Présentation de la technologie LDAP
Les offres logicielles LDAP
|
|
|
|
