Copyright © 2003 Yves MARCOUX; dernière modification: 2003-08-20
Note: C'est volontairement que nous adoptons une vision des choses indépendante de tout corps professionnel. En effet, nous sommes convaincus que la vague de numérisation qui déferle actuellement sur le monde fait en sorte que les compétences et les pratiques ne peuvent plus être cloisonnées comme elles l'ont été jusqu'à maintenant. Il nous semble donc nécessaire de développer une "ontologie" (ensemble de concepts interreliés) plus générale qui chapeaute des concepts relevant jusqu'ici de professions distinctes. C'est dans cette optique que nous évitons de parler de compétences ou de concepts exclusivement reliés à un corps professionnel particulier, par exemple, les informaticiens, les archivistes ou les gestionnaires de documents.
Certains biens utilitaires viennent sans livre d'instructions, par exemple un tournevis, un canif ou un entonnoir. D'autres viennent avec un livre d'instructions qui indique comment les installer, par exemple, une chaîne stéréo, une télévision. Souvent, ces outils nécessitent un raccordement à leur environnement (électricité, câble, téléphone, etc.). D'autres biens nécessitent sans contredit une installation plus songée: un lave-vaisselle encastré, un démarreur à distance, un dispositif d'ouverture mécanique de porte de garage. Dans ces cas, le consommateur a habituellement le choix entre faire l'installation lui-même ou la faire faire par un spécialiste moyennant paiement. S'il décide d'agir seul, le consommateur suivra une procédure bien expliquée dans la documentation; une méthode, une démarche claire et précise, qui marche dans tous les cas.
Plus l'intégration requise entre le bien et son environnement est grande, plus l'implication d'un spécialiste est requise: une piscine creusée, une entrée de garage, un patio. Une simple méthode, qui s'applique à tous les cas, est impossible à élaborer. Une démarche plus complexe s'impose, laquelle doit tenir compte d'une foule de petits facteurs impossibles à prévoir exhaustivement dans une procédure unique. Ce n'est plus une méthode dont on a besoin, mais d'une méthodologie. Une méthodologie ne s'explique pas dans un feuillet d'instructions, elle est trop complexe pour cela. Elle doit s'assimiler par l'expérience et/ou la formation, d'où la nécessité de recourir au spécialiste. La méthodologie n'est pas appliquée par le consommateur, mais par le spécialiste. Elle prévoit la mesure exacte, l'analyse, des besoins et du contexte spécifique du consommateur (par exemple, la grandeur de son terrain).
Une méthodologie représente habituellement une somme de connaissances accumulées par un corps professionnel au fil des ans. Elle permet aux nouveaux du domaine de sauver du temps d'apprentissage en bénéficiant de l'expérience des routiers. (En termes à la mode, c'est un outil de gestion des connaissances au sein de la collectivité que constitue le corps professionnel.) Elle peut être explicite (du genre "Lisez cela et vous vivrez") ou implicite (du genre "Regarde ici, mon jeune, dans un cas comme ça, tu procèdes de telle et telle façon"). Une méthodologie, c'est la mémoire, très efficiente et ergonomique, d'une collectivité de personnes expertes dans la conception et l'installation d'un type d'objets.
Comme méthodologie, le CRGGID s'adresse à des gens qui sont experts dans l'installation de boîtes "gestion des connaissances" dans les ministères et organismes gouvernementaux québécois. Ouf! Qu'est-ce qu'une "boîte gestion des connaissances"? C'est l'ensemble des systèmes et fonctions qui fait qu'un ministère ou organisme arrive à gérer ses connaissances. Est-ce qu'il existe de telles boîtes sur le marché? Non, effectivement, pas comme telles. On se dirige sans contredit vers de telles solutions, avec des systèmes intégrant de plus en plus de fonctions des organisations (les SAP et compagnie) mais, non, il n'y a pas encore vraiment de telles boîtes sur le marché.
Alors, de quoi sont spécialistes les lecteurs du CRGGID? Mettons qu'ils en sont rendus à des systèmes de gestion de l'information. Ah! Alors, ce sont les systèmes informatiques? Oui, certainement, ça inclut ces systèmes; mais aussi ceux qui sont plus souvent oubliés, moins sous les feux de la rampe: les systèmes de gestion de documents. De documents publiés (bibliothèques) et non publiés (archives et documents administratifs).
J'entends déjà les informaticiens s'objecter qu'ils ne font surtout pas des systèmes de gestion de documents; au contraire, depuis des années, ils peinent avec force énergie (et avec raison, du point de vue de la simplicité des systèmes résultants) pour éliminer les documents de leurs systèmes: ceux-ci ont cédé la place aux transactions et aux messages entre objets (ceux du paradigme orienté-objet). Les relents des documents dans les systèmes informatiques modernes sont les entrées de journalisation des SGBD.
Mais voilà. Avec l'avénement du commerce électronique et la volonté de convaincre les consommateurs d'y recourir, la métaphore du document est en train de rattraper les informaticiens. Le consommateur comprend depuis longtemps ce que veut dire "signer un formulaire"; lire une notice légale, etc. Le consommateur se sent sécure s'il a vu de visu un document signé par des parties et s'il sait que ce document reste en arrière-plan durant toute la transaction, prêt à être exhibé comme preuve si cela s'avère nécessaire. C'est donc aux systèmes de s'adapter à ce nouveau besoin: il faut redocumentariser les sytèmes transactionnels pour que le commerce électronique ait du succès; c'est aussi simple que ça!
D'ailleurs, c'est exactement l'approche que prend la Loi québécoise concernant l'encadrement juridique des technologies de l'information. Au Québec, donc, la redocumentarisation des systèmes transactionnels, c'est non seulement la seule façon d'imposer le commerce électronique qui puisse marcher, c'est aussi la loi.
Si vous pensez que la documentarisation des systèmes transactionnels est une approche rétrograde et non naturelle, considérez SOAP. SOAP (Simple Object Access Protocol) est un protocole de communication entre objets basé directement sur XML, le format de documents numériques par excellence. SOAP peut donc être vu comme une forme de documentarisation de transactions. Or, SOAP connaît actuellement un très grand succès dans le contexte des services Web. Cela amène à penser que la documentarisation des systèmes transactionnels est un phénomène naturel quand l'environnement est hautement distribué et faiblement interrelié ("loosely-coupled") comme Internet.
On peut penser que les systèmes transactionnels gouvernementaux ne sont pas des systèmes de commerce, et que, donc, on pourrait faire l'économie de leur redocumentarisation. Mais en réalité, dès qu'il y a paiement, il peut y avoir dispute légale; de plus, les transactions gouvernement-citoyen ont souvent un aspect légal même s'ils n'impliquent pas de paiement. Le sentiment de sécurité entourant les transactions avec le gouvernement doit donc être aussi fort que pour le commerce électronique.
Nous avons donc notre réponse: le CRGGID s'adresse aux experts en conception et implantation de systèmes de gestion des connaissances au Gouvernement du Québec. Cela, c'est dans l'absolu; dans le plus immédiatement applicable, il s'adresse aux experts en conception et implantation de systèmes de gestion de documents: les traditionnels (gestionnaires de documents, archivistes et bibliothécaires) et les nouveaux (les informaticiens, dont les systèmes transactionnels doivent être redocumentarisés). Il faut ajouter que, les systèmes de gestion de documents publiés (ce sont les bibliothèques) étant très bien maîtrisés et opérationnels, le CRGGID n'aura pas directement dans sa mire les bibliothécaires. Ils y seront cependant indirectement, surtout du point de vue de l'intégration de leurs systèmes (bibliothèques) avec les autres systèmes de gestion de documents du Gouvernement.
Selon ce que nous venons de dire du CRGGID, sa méthodologie en serait une, dans l'absolu, de conception et d'implantation de systèmes de gestion des connaissances, et dans le plus pragmatique, de conception et d'implantation de systèmes de gestion de documents. Comme la gestion de documents est un cas particulier de gestion d'information, la méthodologie du CRGGID peut donc être vue aussi comme une méthodologie de conception et d'implantation de systèmes de gestion d'information, qu'on appelle aussi plus simplement systèmes d'information. Pour une raison que nous verrons sous peu, nous préférons parler de méthodologie d'ingénierie de systèmes d'information. Avant de nous pencher sur les particularités de la méthodologie CRGGID, il est utile de considérer d'abord quelques caractéristiques des méthodologies d'ingénierie de sytèmes d'information en général. Cela est d'autant plus utile que les sytèmes informatiques que nous tenterons d'intégrer avec la méthodologie CRGGID ont été en général développés avec l'une ou l'autre des méthodologies d'ingénierie de systèmes d'information.
Pourquoi préférons-nous parler d’« ingénierie » de système plutôt que de « développement »? C’est simplement parce que l’ingénierie est un processus complexe comportant plusieurs étapes, dont le développement du système. Il fallait donc un vocable pouvant chapeauter l’ensemble d’un processus dont le développement n’est qu’une étape. Nous avons choisi « ingénierie » pour faire écho à l’expression anglaise « software engineering ». (Nous évitons « architecture », car ce mot réfère communément à la morphologie d’un système informatique plutôt qu’à une activité.)
Il y a beaucoup de vrai dans l'idée que toutes les méthodologies d'ingénierie (entendre par là: conception de quelque chose devant mener à sa construction et à sa mise en service puis à son évaluation) se ressemblent. C'est bien normal, car toute démarche systématique pour atteindre un but procède naturellement en un certain nombre d'étapes logiques dont la progression est plus ou moins toujours la même. Si on se limite aux méthodologies d'ingénierie de systèmes d'information, alors la ressemblance devient frappante. (Cela ne veut pas dire pour autant qu'elles ont une structure tellement fixe qu'elles en deviennent des recettes. Elles sont toujours fondamentalement des méthodes générales qui demandent à être adaptées à chaque cas particulier.)
À un haut niveau d'abstraction, l’activité d’ingénierie d’un système d’information s'inscrit toujours dans l’une ou l’autre forme du scénario suivant:
|
Collectivité d'utilisateurs à desservir (ex.: membres d'une organisation, groupe d’intérêt, nation) ↓ Besoins de gestion de l’information flous et/ou mal identifiés ↓ Intervention gestion stratégique / planification stratégique / marketing ↓ Besoins bien identifiés ↓ Ingénierie d'un système pour répondre aux besoins bien identifiés ↓ Système répondant adéquatement à certains besoins de gestion de l’information au sein de la collectivité |
Reprenons ces étapes une par une:
Pourquoi prendre la peine de situer l'activité visée par les méthodologies d'ingénierie de systèmes d'information dans un contexte plus vaste? Simplement pour souligner qu'elles ont des limites (comme toute méthodologie, d'ailleurs). Elle ne couvrent pas absolument tout ce qui doit être considéré pour satisfaire les besoins de gestion d'information d'une collectivité. Certains paramètres concernant en particulier la collectivité à desservir et les besoins à satisfaire sont par hypothèse considérés comme connus.
Notons que cela ne signifie pas que les méthodologies d'ingénierie de systèmes d'information ne comportent pas d'étape d'analyse des besoins, au contraire. Mais ce n'est pas une analyse des besoins qui part de rien; elle présuppose un certain débroussaillage préalable, une certaine réflexion déjà faite, par rapport à la portée du système à développer.
Notons qu’a priori, un système d’information n’est pas nécessairement informatisé, ni en tout, ni même en partie. Il reste cependant qu’aujourd’hui, l’informatique est utilisée dans pratiquement tous les systèmes d’information qui sont méthodiquement planifiés et mis sur pied.
Un système d’information peut être de tout type : gestion de comptes de banques, planification financière personnelle, prévisions météo, etc. Parmi ceux-ci, certains sont dits « documentaires ». Un système d’information est dit documentaire lorsqu’il se définit naturellement en termes de gestion d’objets documentaires assez autonomes (ex. : documents, fiches, collections) et dotés d’un certain mode de diffusion systématique (ex. : publication, vente, affichage) au sein d’une collectivité donnée. La gestion d’information publiée ou avec auteur(s) et lecteur(s) bien définis tombe sous cette définition. Exemples : un périodique électronique, une bibliothèque publique.
Lorsque les objets documentaires à gérer sont principalement numériques (ex. : documents numériques), alors on parle de systèmes documentaires d’information numérique ou, plus simplement, de systèmes documentaires numériques; c’est le cas d’un périodique électronique. Notons qu’un système documentaire numérique est forcément au moins en partie informatisé, puisqu’il doit assurer la gestion d’objets documentaires numériques.
La GIE pourrait être définie comme la discipline qui se préoccupe de l’ingénierie de systèmes documentaires d’information numérique pour tout type de collectivités.
Notons tout de suite une classe particulière de systèmes documentaires numériques. C’est le cas où les objets documentaires à gérer ultimement ne sont pas numériques, mais où on utilise des « représentants » (en anglais « surrogates ») numériques des documents réels de façon à pouvoir effectuer la gestion informatiquement. C’est un cas où on devrait plutôt parler de « gestion électronique de l’information », puisque l’information primaire elle-même n’est pas numérique, mais la gestion, elle, l’est.
Le cas d’une bibliothèque publique gérée à l’aide d’un système intégré de gestion de bibliothèque (SIGB) est un exemple de cette situation, de même que celui d’un fonds d’archives (traditionnelles) géré informatiquement. La GED (Gestion électronique de documents) est un autre exemple. Habituellement, les documents à gérer sont des documents (à l’origine) exclusivement sur papier; mais la gestion en est informatisée. Selon notre vision, donc, la GED porte bien son nom et ne saurait être appelée GDE.
Cette distinction étant faite, nous considérerons malgré tout ces systèmes comme des systèmes documentaires numériques. Il faudra cependant être très conscients que les objets documentaires gérés directement (numériques) ne sont que des représentants des « vrais » objets documentaires dont la gestion nous préoccupe, et que le comportement et la performance du système doit être planifiée et évaluée ultimement en fonction de ces « vrais » objets documentaires. Ainsi, par exemple, le fonctionnement et la performance d’un SIGB ne peut pas être évaluée seulement en termes de la gestion des notices catalographiques, mais aussi en termes de gestion de documents matériels. De même, un système de GED doit être évalué et planifié en fonction des exigences posées sur les documents matériels dont elle facilite la gestion (accessibilité, sécurité, valeur probante, etc.).
Pour des questions de qualités et d’efficience, l’ingénierie de systèmes d’information gagne à s’appuyer sur une méthodologie. Ces méthodologies visent à assurer un haut niveau de qualité aux systèmes mis sur pied. Une méthodologie est une approche systématique, appuyée sur des outils intellectuels rigoureux (modèles abstraits, méthodes, etc.), qui permet de guider le travail d’ingénierie d’un système d’information.
Il existe des « zillions » de méthodologies applicables à l’ingénierie de systèmes d’information. L’informatique en propose plusieurs, le domaine de la gestion également. Certaines sont spécialisées pour certains types de systèmes (par exemple, il existe des méthodologies d’ingénierie de systèmes hypermédias). Plusieurs méthodologies sont sans nom; plusieurs sont propriétaires (sous forme de documents vendus et/ou faisant l’objet de formations très onéreuses); plusieurs sont soutenues par des outils « CASE » (Computer-Aided Software Engineering) ou environnements de développement commerciaux. Plusieurs incluent les phases plus générales de planification stratégique.
Certaines méthodologies sont spécialisées pour l’ingénierie de systèmes documentaires numériques. Nous qualifions ces méthodologies de « documentaires ». Elles sont, pour la plupart sinon toutes, issues du monde des sciences de l’information (bibliothéconomie, documentation, archivistique). Pour la plupart sinon toutes, elles s’apparentent, sans être identiques, à des méthodologies existantes du monde de l’informatique ou de celui de la gestion. C’est naturellement à ces méthodologies que la GIE s’intéresse le plus. La GIE consiste, dans une large mesure, en l’étude et l’élaboration de méthodologies d’ingénierie de systèmes documentaires d’information numérique.
Malgré tout, comme nous verrons sous peu, le professionnel de la GIE doit se préoccuper de méthodologies « générales » d’ingénierie de systèmes d’information, car il est possible qu’il doive oeuvrer dans des contextes où ces méthodologies sont appliquées.
Notons que la plupart des méthodologies d’ingénierie de systèmes d’information (documentaires ou non) sont présentées comme des méthodologies de développement informatique ou d’informatisation. Ceci peut sembler en contradiction avec le fait, mentionné précédemment, qu’un système d’information n’est pas forcément toujours informatisé. La contradiction n’est cependant qu’apparente, puisque les méthodologies prévoient toujours le cas où l’informatisation n’est pas appropriée et où le système doit être « manuel ». Il est vrai que cette conclusion est rarement obtenue, mais ce n’est pas parce que les méthodologies ne la prévoient pas, c’est simplement parce que le contexte dans lequel l’ingénierie du système survient est habituellement assez systématique pour faire en sorte qu’une telle conclusion, lorsque valide, est atteinte avant même le démarrage de l’activité d’ingénierie.
Tel que mentionné précédemment, il existe plusieurs méthodologies générales d’ingénierie de systèmes d’information, en voici quelques-unes :
Merise; RUP (Rational Unified Process); Macroscope de DMR (dont un volet [« domaine »] important semble être ProductivityCenter). Le livre de Talbot et Rivard des HEC. Livre sur UML.
Exemple de méthodologie informatique très développée : Software Engineering Methodology (SEM), apparamment développée pour le DOE (Department of Energy) américain. Cette méthodologie complète est disponible sur le Web <http://cio.doe.gov/ITReform/sqse/sem_main.htm>. Elle contient un chapitre sur le développement basé sur des produits COTS (Commercial-off-the-shelf), qui est très intéressant, et explique comment la méthodologie générale doit être adaptée à ce cas. C’est très pertinent pour l’approche GIE, qui est elle aussi basée sur des produits COTS. Entre autres, la nécessité d’approches normalisées pour le développement basé sur des produits COTS est argumentée solidement.
Souvent, ces méthodologies générales sont adaptées à des contextes plus spécifiques, de façon à en alléger l’usage dans ces contextes. Exemple : le Ministère du Revenu du Québec a développé sa propre version simplifiée de Macroscope. L’Office of Energy Research (ER) américain (une division du DOE) a développé sa propre version plus précise et contextualisée de la SEM du DOE, qu’elle appelle simplement ER’s System Development Methodology <http://www.er.doe.gov/production/er-60/98SDM1.htm#98sd11>.
Pour une autre méthodologie, qui semble plutôt moderne, voir <http://webware.princeton.edu/dms/public/methodology/dev/>. Pour toute une liste de méthodologies, voir <http://www.iturls.com/English/SoftwareEngineering/SE_e2.asp>.
Le CMM-SW (Software Capability Maturity Model, promu par l’APIIQ), du Software Engineering Institute, est un modèle qui permet d’évaluer la capacité de maturation qu’entraîne une méthodologie de développement informatique pour une organisation. Plusieurs méthodologies vantent leur qualité par leur score élevé sur les différentes composantes du CMM-SW. Entre autres, Macroscope a été étudié sous cet aspect, de même que la SEM du DOE américain.
Grandes étapes : découverte, conception, développement, implantation, évaluation.
Principaux outils. DFD.
Modélisation orientée données. DER.
Sources intéressantes sur l’ingénierie de systèmes :
Cours donné en 1997 par Gilles Roy à l’UQAR, Département d’économie et de gestion <http://jafar.uqar.uquebec.ca/raroygil/inf115/>.
Models for Action: Developing Practical Approaches to Electronic Records Management and Preservation <http://www.ctg.albany.edu/projects/er/ermn.html>. Contient plusieurs pointeurs vers des documents faits spécialement pour ce projet : sur les modèles de développement informatique, le Workflow, etc.
Vocabulaire, concepts : RAD, JRAD, développement participatif, prototypage
Idéalement, il existerait une seule méthodologie « documentaire » qui subsumerait toutes celles existant actuellement, et qui serait donc applicable quasi-automatiquement à toute situation de mise sur pied d’un système documentaire numérique. Évidemment, cela n’arrivera jamais, ne serait-ce que parce que les analystes ne s’entendraient jamais sur la nature exacte de « la bonne » méthodologie. Le PGIE doit donc composer avec une multitude de méthodologies documentaires. Il lui revient, par son expérience et son jugement, de choisir la méthodologie la plus appropriée à chaque projet spécifique.
Article de Mercure sur le choix d’un logiciel documentaire.
Livre de Jacquesson sur l’informatisation des bibliothèques.
Livre de Maler et El Andaloussi sur le développement de DTD SGML.
Livre de Tenopir et Lundeen.
Mon texte sur la création d’une base de données documentaires.
Les zillions d’ateliers sur la création de bases de données documentaires.
Les méthodologies mises de l’avant en GIE sont proches, dans leurs grands traits, des méthodologies informatiques et de celles de gestion. Cependant, elles diffèrent dans la nature exacte des outils intellectuels (modèles, méthodes, etc.) qui les composent.
Particularités d’une méthodologie documentaire :
1. Quasi-exclusivement basée sur des produits COTS. Pas, ou pratiquement pas, de développement ad hoc.
2. Ne comporte pratiquement aucune étape « programmation » comme telle, mais plutôt de la configuration et/ou de la paramétrisation. En ce sens, elle exploite les capacités « end-user computing » des plate-formes modernes, et confère au PGIE le rôle de développeur par ce truchement.
3. Inclut souvent des passerelles d’exportation/importation entre deux logiciels COTS. Habituellement, ces passerelles se réalisent par paramétrisation d’une fonction d’exportation et/ou d’importation dans l’un ou l’autres des logiciels.
4. Accorde une importance prépondérante à la normalisation.
5. Traduit une grande préoccupation pour l’accessibilité de l’information, ce qui convient particulièrement à l’information publiée et aux collectivités hétérogènes (culturellement et/ou technologiquement). Grande importance, par exemple, à l’internationalité des systèmes développés.
6. Produit des systèmes qui peuvent très bien comporter des étapes de traitement humain (particulièrement : intellectuel, d’analyse de contenu).
7. Exploite les notions d’objets documentaires (ex. : document, fiche, etc.) et de valeur ajoutée via des métadonnées.
8. Met l’accent sur la réutilisation de l’information : c’est un moyen de choix pour la gestion des connaissances au sein d’une collectivité.
9. Considère toutes les possibilités de récupération de l’intelligence générée lors des contacts humain-objet documentaire (ex. : portails interactifs).
10. Tient compte des capacités de traitement automatique des textes disponibles actuellement.
11. Considère que l’information peut être consignée dans des documents, et non seulement dans des bases de données.
12. Tient donc compte des impératifs de gestion documentaire : aspects archivistiques, légaux, confidentialité, signature numérique.
13. Tient compte de l’existence d’outils de gestion des connaissances développés dans le monde bibliothéconomique au cours des âges : thésaurus, systèmes de classification, etc.
14. Tient compte de l’existence de sources systématiques (commerciales ou non) d’information extérieures au système, dans la collectivité elle-même ou à l’extérieur. Autrement dit, situe le système à développer dans son environnement informationnel dès la conception.
Grandes phases : les mêmes cinq que les méthodologies générales