L’e-gouvernment (e-gov) ou gouvernement électronique est une manière fondamentalement nouvelle, intégrée, permettant de fournir des services publics en utilisant de façon optimale les technologies de l’information et de la communication (TIC). En d’autres termes, il désigne l’utilisation des TIC dans les administrations publiques, associée à des changements de l’organisation de celles-ci et au développement de nouvelles aptitudes professionnelles afin d’améliorer la qualité et la fourniture des services publics, les processus démocratiques et de renforcer le soutien des politiques publiques.

« Le gouvernement électronique reflète les visions finales pour que les administrations publiques et les gouvernements subissent une modernisation et une réorganisation énormes » (Wimmer, Krenner, 2001). Cependant, l’e-gov ne se limite pas à la simple mise en ligne d’informations sur les sites Web des administrations publiques. Il implique une profonde refonte de la structure et du fonctionnement des administrations (ce que l’on regroupe sous le vocable "back office"). Les procédures administratives telles que la collecte, le traitement et l’échange électronique des données au sein ou entre administrations, doivent être adaptées à la fourniture de services publics électroniques qui répondent aux besoins des citoyens et des entreprises.

Au Maroc, une panoplie de sites et de services sont mis en ligne : e-Justice (ejustice, 2006), e-Finance (Douane, 2006), DAMANCOM (CNSS, 2006), Agence Nationale de la Conservation Foncière, du Cadastre et de la Cartographie, OMPIC (OMPIC, 2006) , la passation des marchés publics, etc. Ces projets gouvernementaux sont pilotés par le comité e-gov qui se charge d’identifier les grandes lignes de la stratégie et du plan d’actions relatif à la mise en œuvre de l’e-gov, ainsi que du suivi de l’état d’avancement des travaux entrepris et des réflexions menées sur le sujet (Egov, 2006). Le problème posé est que chaque administration a sa propre solution indépendante et ne peut fournir un service intégré. D’où l’absence d’un référentiel commun qui permette d’avoir un portail orienté citoyen et d’éviter les efforts redondants fournis par chaque administration.

Notre objectif est de proposer des patterns processus pour l’e-gouvernement et de contribuer à l’émergence d’un référentiel commun pour l’administration marocaine.

Pour atteindre cet objectif, nous avons procédé à l’étude de quelques architectures internationales comme le guichet unique du gouvernement européen (European One-Stop Government), l’e-Services Development Framework (eSDF) Britannique, la Federal Enterprise Architecture (FEA) Américaine, et quelques solutions applicables à l’e-gouvernement à savoir l’Enterprise Information Portals (EIP) et l’Enterprise Application Integration (EAI). Le résultat de cette étude nous a permis de déduire les convergences technologiques et d’identifier les caractéristiques de base et celles spécifiques d’un portail e-gov. A la lumière de cette étude, nous avons élaboré un système de patterns traitant la conception de l’information d’un portail e-gov, la création, la gestion et la publication de son contenu.

Cet article est organisé comme suit : la section 2 est consacrée à analyser quelques solutions e-gouvernement. Nous en déduisons notre système de patterns pour l’e-gouvernement, présenté en section 3 et formalisé en section 4. Une conclusion dégage les perspectives de notre travail

L’architecture du guichet unique européen a pour objectif d’intégrer en ligne les services publics, avec une perspective centrée sur le citoyen - ou client des services publics. C’est une plate-forme ouverte et évolutive pour l’e-gouvernement (Wimmer, Krenner, 2001), (Tambouris, 2001), (Wimmer, Traunmueller, 2002) , (Mühl, Krabina, 2003).

Les principaux composants techniques de cette architecture sont : le portail gouvernement de nouvelle génération, les répertoires de services, l’environnement de création de services et le Governmental Markup Language utilisé comme outils de développement de cette plate-forme (Glassey, 2002) (Kavadias, Tambouris, 2003) .

Cette architecture est orientée citoyen, et intègre des ressources distribuées et des systèmes existants. Par ailleurs elle fournit un guichet unique qui peut personnaliser un accès multi-canaux et un contenu multilingue. C’est une architecture évolutive, dans le sens où elle permet l’intégration de nouveaux services centralisés ou distribués (services locaux ou services distribués sur d’autres administrations). Elle sépare le concept du front-office de celui du back-office, et fournit des composants réutilisables.

Contrairement à la solution européenne qui est orientée citoyen, le framework eSDF est orienté service. Il fournit une structure de spécification des normes et standards pour l'interopérabilité des services électroniques (e-service) utilisés dans le secteur public. Un e-service est défini comme n'importe quel service électronique impliquant l'interopérabilité entre les systèmes informatiques. Il inclut les données électroniques et les messages échangés entre ces services (Benson, 2002), (GovTalk, 2004).

Ce framework est situé à un niveau d'abstraction plus bas comparativement à la solution précédente. Cependant, il fournit des composants réutilisables pour la planification, la conception et l’implémentation des e-services. Les web services et XML sont recommandés par les normes d'e-GIF (e-Government Interoperability Framework). Ils permettent de réduire les coûts de développement et d’avoir la possibilité de répondre à l’évolution des besoins.

L’objectif de cette architecture est de faire évoluer le gouvernement fédéral américain en privilégiant le résultat. L’architecture FEA est constituée de cinq modèles de référence inter-reliés pour identifier des opportunités de collaboration inter et intra organisations fédérales. Cette architecture décrit les services et les activités du gouvernement fédéral fournis au citoyen, indépendamment des agences, des bureaux, et des organismes qui les fournissent (Feap, 2005).

Chacune des architectures d'EOSG, d'eSDF et de FEA est orientée citoyen ou orientée service. Cependant, il existe un autre type de solutions qui peut être employé pour traiter les aspects décisionnels et de collaboration. Ces solutions sont employées aussi bien pour les secteurs public et privé : ce sont les portails d’information d'entreprise (EIP) et l'intégration d'applications d'entreprise (EAI), que nous présentons dans la sous-section suivante.

Les buts d’un portail d’entreprise sont de mettre à disposition une interface unique, personnalisable, pour accéder à l’ensemble des informations requises par un client, un partenaire ou un employé. Il s’agit de transformer l’information en connaissance en lui donnant un sens dans un contexte d’utilisation. Il s’agit d’un amalgame d’applications informatiques qui consolident, gèrent, analysent et distribuent l’information à la fois à l’intérieur et vers l’extérieur de l’entreprise. Ces logiciels comprennent les outils d’aide à la décision (Business Intelligence), de gestion du contenu (Content Management), les entrepôts de données (Datawarehouse et Data Marts) et les applications transactionnelles (Shilakes, Tylman, 1998).

L'EAI a pour objectif l'intégration et l'interconnexion des différents composants d'une infrastructure informatique : bases de données, plates-formes, applications, serveurs centraux ou départementaux, informatique personnelle, équipements mobiles, etc. Sa démarche est un processus d’intégration d’applications développées indépendamment, utilisant des technologies incompatibles et devant continuer à être gérées séparément (DataExchanger, 2002), (Mediadev, 2002), (Cosmobay, 2000). La flexibilité, l’évolutivité et l’adaptabilité, aujourd’hui indispensables au maintien de la compétitivité de l’entreprise, sont également des bénéfices stratégiques qui découlent de la mise en œuvre de ces solutions.

Pour répondre à de telles exigences, les plates-formes d’EAI imbriquent quatre couches technologiques : le moteur d’intégration, les composants, l’extraction de données et le transport de données.

Nous avons pu, à travers cette étude, déterminer quelques éléments significatifs permettant de comparer ces différentes solutions dans le tableau 1 (Ouchetto, Chiadmi et al., 2005).

En se basant sur cette synthèse, nous déduisons les caractéristiques communes suivantes:

• Toutes les architectures ont les mêmes tendances technologiques :

• - XML est une nécessité pour le développement des plates-formes e-gouvernement

• - Les web services sont devenus un facilitateur d’intégration

• Les différentes architectures ont les mêmes tendances en terme de besoins : le citoyen est au centre de l’architecture

• Le multicanal est indispensable pour les architectures e-gouvernement

• L’intégration des legacy systèmes est prise en charge par ce type d’architecture

• Les architectures sont évolutives

Ces caractéristiques communes nous ont permis d’élaborer un système de patterns qui va aider le concepteur à mettre en place un portail e-gov. Ce système est présenté dans la section suivante.

A la lumière des solutions décrites ci-dessus, nous avons proposé un système de patterns processus dédiés au concepteur de portails e-gov. L’objectif est d’offrir des procédures facilitant la conception d’un portail e-gov. Cela permet d’enrichir cette conception et d’éviter les simples mises en ligne de services publics. Ce système est structuré en quatre patterns à savoir la «Conception du portail », la « Création du contenu », la « Gestion du contenu » et la « Publication » comme l’indique la figure 1.

Les sous-sections suivantes présentent les quatre patterns cités ci-dessus.

La conception d’un portail e-gouvernement est une phase de spécification antérieure à la mise en œuvre de son architecture. Il s’agit principalement de porter l’effort sur la capacité à identifier, capturer, stocker et fournir des masses d’information importantes, en provenance de sources multiples et hétérogènes. La mise en œuvre d’un portail e-gouvernement permet de libérer l’accès à l’information de l’administration publique et de fournir un point d’accès central à l’information personnalisée requise. C’est aussi une occasion de rationaliser l’architecture et l’urbanisme, en organisant la communication entre certaines applications et, si nécessaire, la communication globale du système. La phase de Conception du portail e-gouvernement permet de définir plusieurs niveaux : Structuration des informations, Gestion des métadonnées, Intégration des services électroniques (intégration d’applications ou de données externes) et Adaptation de l’interface utilisateur (cf. figure 2).

Le pattern Création de contenu concerne la production de nouveaux contenus. L’objectif de ce pattern (cf. Figure 3) est de décrire comment les nouveaux contenus vont être créés (Formulaires), avec quels outils collaboratifs on peut enrichir le portail (Outils collaboratifs), et comment les Composants d’intégration peuvent assurer l’intégration d’un e-service.

Le pattern Gestion du contenu a pour objectif de définir comment le contenu va être administré, comment la recherche de l’information peut être faite en utilisant des méta données (auteur, date de création, ...), comment la gestion des documents et leur versions est effectuée, quand et comment archiver les données et comment sécuriser les données pour rendre un service de qualité. La figure 4 décrit les patterns qui lui sont reliés.

Les fonctionnalités du pattern Publication du contenu sont liées à la satisfaction de l’utilisateur et peuvent être des facteurs critiques dans l’acceptation et l’utilisation du portail. En effet, les utilisateurs auront du mal à adopter le portail e-gouvernement si celui-ci n’est pas à leur mesure, s’il n’est pas facile à utiliser ou n’est personnalisé, d’où la hiérarchie de paterns présentée en figure 5.

Nous présentons dans la section suivante la formalisation de quelques patterns à savoir la gestion de la sécurité et la gestion des utilisateurs, l’adaptation de l’interface, publication du contenu, personnalisation et présentation.

Le formalisme retenu comprend les rubriques communes aux principaux formalismes de patterns. Il est constitué de quatre principales parties : le contexte, le problème, les forces et la solution. Il décrit la relation entre le contexte, le système de forces qui se produisent à plusieurs reprises dans ce contexte et la solution permet à ces forces de se constituer.

Parmi les patterns décrits par Ouchetto (2006), nous présentons à la suite les quatre patterns formalisés Gestion de la sécurité, Adaptation de l’interface, Publication de contenu et Personnalisation.

La sécurité est une stratégie qui doit être prise en compte pour toute solution e-gouvernement En effet, les portails fournissent un accès centralisé aux données de nombreuses applications et bases de données, chacun disposant de ses propres mécanismes de sécurité. Ces mécanismes doivent être intégrés et fédérés au sein d’un méta-référentiel qui centralisera l’identification de l’utilisateur en une seule procédure. Si un accès sécurisé s’avère donc inévitable, il va falloir disposer d’un contrôle centralisé, connaissant chaque utilisateur, les applications pour lesquelles il possède un droit d’accès et, parfois plus encore, les fonctions des applications qu’il peut exploiter. Cela implique non seulement de fédérer les annuaires utilisateurs externes disponibles dans l’entreprise, mais également les référentiels internes des applications et des progiciels.

La communication entre le référentiel de sécurité et celui des applications jouera un rôle crucial dans la robustesse d’ensemble de la solution et dans la perception et l’acceptation du portail par les utilisateurs. À un autre niveau, la possibilité de diffuser des données ou des documents sur des protocoles sécurisés cryptés doit également être considérée attentivement en fonction du caractère confidentiel des informations véhiculées, surtout si le portail a une vocation externe. Nous présentons dans ce qui suit la formalisation de ce pattern.

Gestion de la sécurité

Le guichet unique implique un vaste échange d'informations, les échanges électroniques de données entre les acteurs de l'e-gouvernement exigent des niveaux de sécurité croissants à mesure que les projets quittent les simples sites d'information pour se diriger vers le guichet unique.

• L'administration électronique s'expose, de manière directe, à toute la panoplie des risques connus en matière de fiabilité et de sécurité dans un environnement informatique (vie privée et confidentialité, l’intégrité des données transmises, la preuve de l’identité, transactions….etc.).

• L'autorité publique est dans l’obligation de pouvoir garantir un environnement Internet suffisamment sécurisant.

• La sécurité est régulièrement pointée comme le frein le plus important au développement de la "nouvelle économie".

• On s'attendrait à ce que l'administration montre l'exemple de sécurité.

• L’administration gère les secrets de l’Etat.

• L’administration doit donner qualité de service et la sécurité nécessaire pour faire face à l'augmentation attendue des échanges électroniques d'information dans le cadre des projets d'e-gouvernement.

Comment le portail e-gouvernement peut-il rendre au citoyen un service sécurisé et de qualité?

• L'identification des utilisateurs doit être assurée de manière à refuser l'accès aux intrus.

• Chaque transaction doit être prouvée.

• La communication interne des données entre les différentes administrations doit également être sécurisée.

• La carte d'identité électronique sera une des clés qui permettra l'échange de données sécurisé entre les usagers de l'e-gouvernement et le portail unique (sites web et applications accessibles en ligne).

• Au sein de l'Administration, il faudra évoluer vers l'étape ultime qu'est le single sign-on sécurisé c'est-à-dire un système où chaque utilisateur doit s'identifier une seule fois pour obtenir l'accès aux informations dont il a besoin et modifier celles dont il est gestionnaire.

• Diffuser des données ou des documents sur des protocoles sécurisés cryptés doit également être considérée attentivement en fonction du caractère confidentiel des informations véhiculées

• Mettre un référentiel de sécurité qui regroupe toutes les applications et services et leurs droits d’accès tout en coopérant avec le référentiel des utilisateurs.

• Mettre en place une équipe veillant à tester régulièrement la fiabilité de l’existant.

• Assurer la formation et la veille technologique en matière de sécurité.

-- Fin du pattern

Dans un projet e-gouvernement, l'adaptation d'une interface doit être caractérisée par deux propriétés : l'adaptabilité et l'adaptativité. L'adaptabilité est la capacité d'une interface à être modifiée par l'utilisateur, et l'adaptativité est la capacité d'une interface à se modifier automatiquement, sans action explicite de l'utilisateur. L'espace d'adaptation est défini par les axes suivants : la cause de l'adaptation, l'objet qui s'adapte, le moment de l'adaptation et l'acteur qui déclenche l'adaptation.

Nous pouvons définir l’objectif, l’adaptation, par le slogan suivant : "Spécifier une fois, générer plusieurs fois". Pour réaliser cet objectif, nous proposons un processus de conception de l’adaptation de l’interface utilisateur. L’idée est d'encapsuler le plus d'informations possibles dans des modèles pour faciliter le développement d'une interface, voire l'automatiser. Cette approche est assez sophistiquée puisqu'elle cherche à couvrir non seulement tous les composants du modèle architectural mais aussi à injecter d'autres connaissances spécifiées dans des modèles tels que le modèle de l'utilisateur, de l'environnement, du comportement, des tâches, d'ergonomie, de la plate-forme. Le formalisme de ce pattern est la suivante.

Adaptation de l’interface utilisateur

Vous êtes en phase de conception des informations d’un portail e-gouvernement.

Vous cherchez à rendre l’accès au portail unique et personnalisé.

• Le citoyen est au centre de l’architecture e-gouvernement

• L’interface utilisateur doit être adaptable et adaptative

• L’interface est spécifiée une fois pour être générée plusieurs fois

Comment peut-on concevoir une interface utilisateur assurant l’adaptation ?

• Encapsuler le plus d'informations possible dans des modèles pour faciliter le développement d'une interface, voire l'automatiser.

• Concevoir les mécanismes d’adaptation dans la conception du portail

Ces modèles sont schématisés dans le schéma suivant :

Le modèle de l'arbre de tâche utilisateur est une transcription formelle ou semi-formelle de l'activité de l'utilisateur dans le mode réel. Ce modèle doit être réalisé par un spécialiste en sciences cognitives.

Le modèle de l'environnement décrit le contexte d'utilisation. Ce modèle n'est pas clairement défini dans la littérature. Nous y spécifions les objets qui peuvent avoir un impact ou sont en relation avec la réalisation d'une tâche. Ces objets peuvent être une personne, un lieu, des événements, etc.

Le modèle des concepts du domaine décrit les données en relation avec la réalisation des tâches de l'utilisateur. Ce modèle est une description d'un sous-ensemble du noyau fonctionnel.

Le modèle de tâches système décrit comment les tâches utilisateurs sont implémentées dans le système.

Le modèle de l'interface utilisateur abstraite est la première étape vers la génération de l'interface finale. A partir de l'arbre de tâches système, sont déterminées les informations à représenter et comment elles sont regroupées.

Le modèle de la machine décrit les possibilités de la plate-forme visée : performances de calcul, performances de communication, dispositifs physiques d'interaction, etc.

L'interface utilisateur finale est la spécification de l'interface finale. Elle est générée automatiquement ou semi-automatiquement à partir des modèles précédents.

-- Fin du pattern

Comme nous avons décrit ce pattern dans la section 3.4, nous présentons ci-dessous son formalisme.

Publication du contenu

Vous êtes un concepteur de portails

Vous cherchez à publier le contenu d’un portail e-gov

• Les utilisateurs ont besoin d’avoir du contenu sous diverses formes.

• L’interface du portail doit être personnalisée selon le profil de l’utilisateur.

• L’utilisateur doit être au centre de l’architecture du portail.

Comment le portail e-gouvernement peut-il offrir un contenu qui réponde aux besoins des utilisateurs?

• Maintenir un profil à chaque utilisateur

• Personnaliser le contenu du portail

• Rendre le profil utilisateur dynamique en fonction son activité

• Mettre en place une politique informationnelle afin d’informer les utilisateurs des changements qui les intéressent

Présentation, Personnalisation et Notification

-- Fin du pattern

Nous présentons dans ce qui suit un pattern lié à la publication de contenu.

Il s’agit de filtrer l’information pour correspondre à l’activité et aux préférences de l’utilisateur. L’importance de la phase de personnalisation est incontestable. Elle correspond aux droits d’accès (l’utilisateur accède aux données et applications auxquelles il a droit), au filtrage des données (l’utilisateur extrait un sous-ensemble des données qui l’intéressent et retrouve ces préférences) et au profiling (l’application personnalise le contenu en fonction de sa compréhension de la navigation de l’utilisateur). La description de ce pattern est la suivante.

Personnalisation du contenu

Vous êtes un concepteur de portails

Vous cherchez à publier le contenu d’un portail e-gov

• Les utilisateurs ont besoin d’avoir du contenu sous diverses formes.

• L’interface du portail doit être personnalisée selon le profil de l’utilisateur.

• L’utilisateur doit être au centre de l’architecture du portail.

• L’utilisateur cherche d’avoir une interface adaptable

Comment peut-on personnaliser le contenu d’un portail e-gouvernement?

Personnaliser l’information en modélisant le profil utilisateur. Cette modélisation doit pouvoir capturer toutes les dimensions qui représentent l’utilisateur. A notre sens, ces dimensions sont de trois types : les préférences, les données personnelles et les données de l'environnement.
1. La dimension des préférences contient l'ensemble des informations liées aux préférences de l'utilisateur. Elle se décompose en deux sous catégories : domaine d'intérêts, informations caractérisant les centres d'intérêts de l'utilisateur, et préférences de recherche renferme l'ensemble des préférences de l'utilisateur. Ces préférences sont liées aux informations recherchées portant sur le processus de recherche (temps de réponse), sur l’information recherchée (contenu et contenant) et sur la customisation des résultats (livraison, mise en page).
2. La dimension des données personnelles décrit l'ensemble des informations personnelles de l'utilisateur concernant son identité et sa profession.
3.La dimension des données de l'environnement contient les données sur l'environnement de recherche de l'utilisateur : l'emplacement géographique, la configuration logicielle et matérielle.

Maintenir un profil à chaque utilisateur

Rendre les profils utilisateurs dynamiques

Filtrer et classer l’information suivant le profil utilisateur

Associer des rôles aux utilisateurs de telle sorte que qu’un utilisateur peut jouer plusieurs rôles que son profil prend en compte

-- Fin du pattern

Nous avons essayé à travers cette réflexion de proposer un cadre structurel pour la mutualisation des savoirs faire en matière de l’e-gouvernement. Il se traduit par un ensemble de patterns processus dédiés au concepteur de portails e-gov. L’objectif est d’offrir des procédures pour guider la conception d’un portail e-gov et favoriser la prise en compte des différentes dimensions d’une application e-gov dès le démarrage du projet. D’une part, cela permet d’enrichir le contenu et d’éviter les simples mises en ligne des services publics et surtout d’adopter une approche commune. D’autre part, nous espérons que cette première étape favorisera la mutualisation et la convergence des initiatives gouvernementales et permettra l’émergence d’une solution commune. Nous avons ainsi formalisé notre solution sous forme d’un système de patterns. Nous l’avons structuré en quatre systèmes de patterns à savoir la conception du portail, la création du contenu, la gestion du contenu et sa publication.

Comme perspective de notre travail, nous comptons développer le noyau du système de patterns que nous avons proposé et décrit d’une manière horizontale et de les évaluer en se basant sur un cas pratique.