Copyright © 2001-2007 Yves MARCOUX; dernière modification de cette page: 2007-09-09
Yves MARCOUX - EBSI - Université de Montréal
Au sens où nous l'entendons, le mot méthodologie signifie toute méthode ou façon d'effectuer une tâche, d'une complexité suffisante pour qu'il soit impossible de l'assimiler à une simple « recette » ou procédure mécanique. Certainement, les approches adéquates pour « gérer » quoi que ce soit d'une quelconque complexité ne peuvent se ramener à des recettes applicables de manière automatique, et peuvent donc être considérées comme des méthodologies.
Le fait de ne pas être applicable en mode automatique n'empêche pas une méthodologie de proposer une démarche systématique, c'est même une caractéristique essentielle à son utilité. Seulement, les étapes proposées ne peuvent se ramener à l'applications de règles entièrement codifiées; au contraire, elles feront nécessairement appel au jugement de la personne qui applique la méthodologie. Une méthodologie s'adresse donc à un professionnel, qui devra faire preuve/usage de jugement, de déontologie, d'éthique. On pourrait ajouter d'expérience, mais on peut être professionnel même sans expérience, bien que l'expérience soit évidemment souhaitable. En fait, une définition intéressante de professionnalisme est, croyons-nous:
Un professionnel est donc quelqu'un capable d'acquérir de l'expérience, même s'il n'en possède pas ou peu au début de sa pratique ou carrière.
Pour l'acquisition des compétences 1, 2 et 7 (honnêteté, jugement et capacité à apprendre de ses expériences), les études ont probablement peu à offrir; on peut penser que le développement de ces compétences passe plus par l'exposition à des modèles à suivre que par l'étude. Les connaissances déontologiques (5) s'acquièrent en se familiarisant avec les codes de déontologie de différents groupes professionnels. Par exemple, l'Association professionnelle des informaticiens et informaticiennes du Québec (APIIQ) a son code de déontologie <http://www.apiiq.qc.ca/public/rapports/fr_codedeon94.html> (Code de déontologie des informaticiens et informaticiennes du Québec, Troisième édition, 1994). D'autres codes de déontologie, dont ceux de l'Association des archivistes du Québec et de la Corporation des bibliothécaires professionnels du Québec, sont répertoriés au <http://www.ebsi.umontreal.ca/voir/scinfo.htm#codes>. L'apprentissage de type académique (scolaire) est tout indiqué pour les compétences 3, 4 et 6.
L'objectif du présent texte est de présenter des éléments de connaissance méthodologique à l'intention de professionnels de la gestion d'information numérique (PGIN).
Pour quels types de tâche une approche méthodologique est-elle appropriée? Sûrement plusieurs, mais on peut au moins identifier les deux suivants:
En fait, il n'est pas faux de dire que le second type est un cas particulier du premier. Cependant, la mise sur pied de systèmes est un type de tâche « stéréotypé », qui peut très naturellement servir d'objectif pour un groupe. C'est un type de projet facilement mobilisateur, qui peut bien se découper, autant dans le temps qu'en termes de responsabilité (qui le dirige, qui y participe, qui utilisera le système résultant, etc.). Pour cette raison, la mise sur pied de systèmes est un type de tâche pour lequel un très grand nombre de méthodologies ont été développées.
Pour les tâches du premier type, qui sont moins stéréotypées que la mise sur pied de systèmes, on parlera souvent d'approches ou méthodes générales de gestion, plutôt que de méthodologies proprement dites, bien que l'appellation méthodologie ne soit pas erronée. Ce genre d'approches est parfois très général et peuvent être trop peu spécifiques pour être d'une grande utilité lorsque le projet à réaliser est effectivement la mise sur pied d'un système. Un autre exemple d'approches très générales sont celles du genre « résolution de problèmes », certes très utiles dans beaucoup de situations, mais, encore une fois, peut-être être trop peu spécifiques pour être vraiment utiles dans la mise sur pied d'un système.
Souvent, une même activité peut être vue comme la réalisation d'un projet ou comme la mise sur pied d'un système. Par exemple, l'informatisation d'une bibliothèque peut être considéré comme un projet à réaliser par le personnel d'une bibliothèque, mais aussi comme la mise sur pied de la nouvelle « version » de la bibliothèque (vue comme un système), dans laquelle certaines fonctions seront informatisées. La différence est subtile, mais la vision systémique amènera tout naturellement à adopter, ou à tout le moins considérer, une méthodologie de mise sur pied de système.
Une des raisons pour lesquelles nous préconisons une approche systémique pour encadrer l'intervention GIN est que, d'une part, elle positionne clairement celui-ci comme un professionnel avec des connaissances méthodologiques autant que techniques, et—surtout—le place sur le même terrain—ou « marché »—que d'autres professionnels avec lesquels il est en concurrence, notamment les informaticiens. Effectivement, l'informatique s'est très clairement orientée, dans les deux dernières décennies, vers l'utilisation de méthodologies sophistiquées et éprouvées pour la mise sur pied de systèmes ou solutions informatiques. À notre avis, il y a place, sur le marché de la gestion de l'information, pour les deux types de professionnels, dont les compétences sont proches mais complémentaires, et l'affirmation de l'existence et de l'utilisation d'une méthodologie (ou plus!) adaptée à l'intervention GIN est essentielle à la reconnaissance et à l'acceptation de la place du PGIN dans ce marché.
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 professionnel 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 importante et complexe, plus l'implication d'un professionnel est requise: une piscine creusée, une entrée de garage, un patio. Une simple méthode d'installation, qui s'applique à tous les cas, devient impossible. 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. L'installation de l'objet est devenue un véritable projet. Si l'on adopte une vision systémique des choses, le projet peut-être vu comme la conception et la réalisation d'une « prochaine version » d'un système, laquelle intégrera de façon appropriée le nouvel objet. De ce point de vue, c'est d'une méthodologie de mise sur pied de systèmes dont on a besoin.
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 professionnel. La méthodologie n'est pas appliquée par le consommateur, mais par le professionnel. 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 est en quelque sorte un outil de gestion des connaissances au sein d'une collectivité de professionnels, qui leur permet de ne pas constamment réinventer la roue. Elle permet aux nouveaux du domaine de sauver du temps d'apprentissage en bénéficiant de l'expérience des routiers. Elle peut être consignée (expliquée dans des documents) ou non (basée par exemple sur une transmission orale du savoir: « Regarde, dans ces cas-là, on fait comme ci et comme ça »). Évidemment, une méthodologie consignée est beaucoup plus utile qu'une méthodologie non consignée.
Pourquoi parlons-nous de méthodologie de « mise sur pied » de systèmes, plutôt que de méthodologie de « développement » de systèmes? Simplement parce que, comme nous verrons, la mise sur pied d'un système comporte plusieurs étapes, et que le développement du système n'est qu'une de ces étapes. Il fallait donc un vocable pouvant chapeauter l'ensemble d'un processus dont le développement n'est qu'une étape. Nous aurions pu choisir « ingénierie », pour faire écho (entre autres) aux expressions anglaise « software engineering » et française « ingénierie documentaire », mais le terme pourrait soulever des questions de prérogatives professionnelles, que nous préférons éviter. Également, « ingénierie » a une connotation technique exagérée qui pourrait être trompeuse ou même préjudiciable au PGIN. Nous évitons par ailleurs le terme « architecture », car il désigne habituellement la morphologie d'un système plutôt qu'une activité.
Un type particulier de système est le système de gestion d'information ou, plus simplement, système d'information. 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.
Une collectivité, c'est à peu près n'importe quel regroupement de personnes que l'on puisse imaginer. Par exemple: les habitants d'une municipalité; une communauté universitaire; une organisation, avec ou sans but lucratif; géographiquement, culturellement, économiquement et technologiquement homogène ou hétérogène; dépendante de clients-payeurs ou non. Le PGIN ne voit pas d'opposition, mais plutôt une complémentarité fertile, entre les façons de mettre sur pied un système dans un contexte compétitif et dans un contexte communautaire.
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 GIN 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, au sens originel de gestion de documents papier par des moyens informatiques, incluant la numérisation des documents) est un autre exemple. Les documents à gérer sont à l'origine des documents papier; mais la gestion en est informatisée. Selon notre vision, donc, la GED, dans ce sens, 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 doive ê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.).
Avant de nous pencher sur quelques caractéristiques des méthodologies de mise sur pied de systèmes d'information, regardons d'abord le contexte dans lequel s'inscrit habituellement cette activité. D'un point de vue très général, l'activité de mise sur pied 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 d'information flous et/ou mal identifiés |
| ↓ |
| Intervention gestion stratégique / planification stratégique / marketing |
| ↓ |
| Besoins bien identifiés |
| ↓ |
| Mise sur pied du système |
| ↓ |
| Système répondant adéquatement aux besoins identifiés |
Reprenons ces étapes une par une:
Tout commence par une collectivité au sein de laquelle commence à se faire sentir un vague besoin de gestion d'information. Certains individus émettent l'idée, par exemple, qu'on « devrait faire un site Web » ou encore « développer une base de données » ou « mettre sur pied une chaîne téléphonique » pour telle ou telle raison.
Plus ou moins explicitement, quelqu'un reçoit le mandat d'analyser sommairement ces besoins flous en buts plus précis, après avoir vérifié comment ils peuvent s'inscrire dans la mission ou les buts de la collectivité et peut-être avoir mesuré plus précisément l'ampleur de certains besoins (marketing).
De cette activité, ressortent des besoins beaucoup plus précisément formulés, dont tous sont en mesure de constater l'adéquation avec la mission ou les buts de la collectivité.
C'est à partir de ces besoins plus précis que s'effectue la mise sur pied d'un système destiné à les satisfaire.
Le résultat final est, en principe, un système (pas forcément informatique, évidemment) qui répond adéquatement à certains des besoins de gestion d'information de la collectivité qui avait ressenti des besoins au début du processus.
Pourquoi prendre la peine de situer l'activité visée par les méthodologies de mise sur pied de systèmes d'information dans un contexte plus vaste? Simplement pour souligner qu'elles ont des limites (comme toute méthodologie, d'ailleurs). Elles 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 supposés connus.
Tel que souligné précédemment, pour des questions de qualité et d'efficience, la mise sur pied 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 de mise sur pied d'un système d'information. Rivard et Talbot (1992, p. 32) définissent une approche méthodologique comme étant « un ensemble d'étapes et d'outils qui permettent de discipliner le processus de développement de systèmes en le rendant rigoureux, donc plus facile à gérer ».
Il existe une myriade de méthodologies applicables à la mise sur pied 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 de mise sur pied 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 (ou de « pré-faisabilité », etc.).
Certaines méthodologies sont spécialisées pour la mise sur pied 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 GIN s'intéresse le plus. La GIN 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 PGIN 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 œuvrer dans des contextes où ces méthodologies sont appliquées.
Notons que la plupart des méthodologies de mise sur pied 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é de mise sur pied du système.
Il y a beaucoup de vrai dans l'idée que toutes les méthodologies de mise sur pieds de systèmes (entendre par là: conception de quelque chose menant à sa construction et à sa mise en service) 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 de mise sur pied de systèmes d'information, cependant, 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.)
La structure générale des méthodologies de mise sur pied de systèmes d'information est bien exemplifiée, croyons-nous, par le parcours « Catalyst 4D » de la méthodologie « CSC Catalyst » de la firme Computer Sciences Corporation, parcours qui adopte la structure générale suivante:
Nous avons ajouté les deux dernières étapes, qui complètent le cycle de vie de tout système d'information. L'étape 6 renvoie à l'étape 1 quand le résultat de l'évaluation indique que les besoins ou le contexte du système ont changé au point de rendre nécessaire un retour à la planche à dessin pour une prochaine version du système. Les étapes 5 et 6 sont parfois absentes, parce que le processus est vu du point de vue d'un consultant dont le mandat ne prévoit pas de suivi après l'implantation du système. D'un point de vue global, cependant, ces étapes sont essentielles.
Le PGIN est à l'informaticien ce que l'architecte est à l'ingénieur en bâtiment. L'ingénieur se préoccupe de résistance des matériaux, d'épaisseur de murs, de type de poutres, alors que l'architecte se préoccupe d'intégration d'une construction dans son environnement, d'ensoleillement, de ventilation; bref, des besoins des utilisateurs. Si l'on voit un système d'information comme une construction, les préoccupations du PGIN se transposent exactement en celles de l'architecte. Évidemment, plus le PGIN en connaît en informatique, mieux c'est, mais ce n'est pas la compétence la plus recherchée par les collectivités « clientes » (qui, souvent, comptent déjà des informaticiens dans leur rang). Le PGIN doit maîtriser les principaux modèles de gestion de l'information numérique disponibles sur le marché (par exemple: bases de données textuelles, relationnelles, hypermédia, portails, outils de collaboration), mais il n'est pas nécessaire, par exemple, qu'il sache programmer (bien que cela puisse être utile). L'essentiel est qu'il soit un interlocuteur compétent et crédible, et aussi qu'il puisse mettre en place de façon autonome certaines solutions simples (par exemple, une base de données, un site Web ou un intranet simple), plutôt que de toujours recourir à de l'aide externe.
La GIN n'est pas de la « sous-informatique ». Un PGIN doit avoir un bagage informatique, mais n'a pas besoin d'être un informaticien chevronné. Inversement, un informaticien chevronné, mettons qui possède un baccalauréat en informatique, n'est pas automatiquement un PGIN chevronné. Comme nous verrons plus tard, le PGIN possède certaines connaissances et préoccupations que l'informaticien n'a que rarement; par exemple, des connaissances sur la problématique de la gestion des documents. C'est ce qui justifie la présence de l'option GIN dans la MSI de l'EBSI; autrement, ce serait une spécialisation de l'informatique.
Contextes où le PGIN peut œuvrer sans informaticien: projets pilotes, prototypes, contextes très standard. (Et, bien sûr, les cas où le PGIN s'est donné des compétences poussées en informatique.)
Contextes où le PGIN peut difficilement œuvrer sans informaticien: impératifs de sécurité ou de performance très forts, contextes peu standard (p.ex. développer des visites virtuelles d'un musée).
Contextes où le PGIN doit assurer tout ou partie de la planification stratégique: petits projets lancés sans approche méthodologique solide; parfois, cet aspect stratégique doit même être fait rétrospectivement.
Tel que mentionné précédemment, il existe une myriade de méthodologies générales d'ingénierie de systèmes d'information, en voici quelques-unes:
Pour une autre méthodologie, 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>.
Exemple de méthodologie informatique très développée : Software Engineering Methodology (SEM), apparemment 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/download/SEM3_1231.pdf>. 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 GIN, 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.
L'approche Capability Maturity Model® Integration (CMMI) <http://www.sei.cmu.edu/cmmi/>, du Software Engineering Institute de l'Université Carnegie Mellon, est une méthode générale d'amélioration de processus (Process Improvement) basée sur l'intégration de modèles de maturité des habilités (Capability Maturity Models). CMMI intègre plusieurs modèles de maturité des habilités, et plusieurs méthodologies informatiques ou de gestion vantent leur qualité par leur score élevé selon ces différents modèles. Par exemple, Macroscope de Fujitsu Consulting (DMR), la SEM du DOE américain et Catalyst de CSC, toutes trois déjà mentionnées, ont été étudiées de ce point de vue.
Parmi les principaux outils: DFD (data flow diagrams, ou diagrammes de flot de données). Pour une modélisation orientée données: DER (diagramme entité-relation).
RAD: rapid application development (développement agile); de Steve C McConnell
« RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. This has a number of distinct advantages over the traditional sequential development model. » Source: <http://www.credata.com/research/rad.html>.
JAD (Joint Application Development): <http://www.utexas.edu/hr/is/pubs/jad.html>.
JAD Philosophy: The JAD process is based on four simple ideas:
1 People who actually do a job have the best understanding of that job. 2 People who are trained in information technology have the best understanding of the possibilities of that technology. 3 Information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and effect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community. 4 The best information systems are designed when all of these groups work together on a project as equal partners.
Développement participatif:
« La méthode vise à impliquer systématiquement les utilisateurs durant toutes les étapes du développement d'un système informatique, depuis sa conception jusqu'à son évaluation. Les utilisateurs ne sont pas seulement des acteurs passifs que l'on consulte, mais ils sont intégrés à l'équipe de conception de l'application. » Source: <http://egov.wallonie.be/boite_outils_methodes/pa031005.htm>.
Prototypage évolutif:
« ... la production rapide d'un prototype, version partielle et économique du système à produire... Dans cette méthode, un prototype est évalué par le développeur et le client, ou par le développeur seul (dans le cas où l'objectif du prototype est l'évaluation d'une solution à un problème de design); les améliorations à apporter au prototype sont mises en évidence et incorporées dans la version suivante (par exemple des améliorations de spécifications et de design, des spécifications supplémentaires). Ce cycle production-évaluation d'un prototype est répété jusqu'à atteindre un produit satisfaisant les besoins du client. » Source: <http://www.algo.be/cl/method.htm>.
Agile modeling:
« Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner. The practices of AM should be used, ideally in whole, to enhance other, more complete software process such as eXtreme Programming (XP), the Microsoft Solutions Framework (MSF), the Rational Unified Process (RUP), and the Enterprise Unified Process (EUP) to name a few. These processes cover a wider scope than AM, in the first three cases the development process and in the fourth the full software process including both development and production. Although these processes all include modeling and documentation activities, in one form or the other, there is definitely room for improvement. In the case of XP and MSF the modeling processes should be better defined, and in the case of both the RUP and the EUP the modeling processes could definitely stand to be made more agile. » Source: <http://www.agilemodeling.com/essays/agileModelingRUP.htm>.
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 PGIN 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.
Exemples de méthodologies documentaires plus ou moins développées:
Source intéressante sur l'ingénierie de systèmes d'information avec une forte préoccupation archivistique: Center for Technology in Government, Université d'Albany (NY) <http://www.ctg.albany.edu/tools/tools?chapter=tools>. Entre autres: Models for Action: Developing Practical Approaches to Electronic Records Management and Preservation <http://www.ctg.albany.edu/projects/mfa>.
À un haut niveau d'abstraction, les méthodologies documentaires, celles mises de l'avant en GIN, ne sont pas différentes des autres méthodologies informatiques et de gestion. Cependant, elles diffèrent dans la nature exacte des outils intellectuels (modèles, méthodes, etc.) qu'elles proposent. Elles adoptent une vision « documentaire » de l'information—particulièrement bien adaptée au contexte du Web et de la « prestation électronique de services » (PES)—qui se reflète dans le détail des méthodologies, et qui fait qu'elles peuvent sembler, au premier abord, très différentes des méthodologies générales de développement informatique (DMR Macroscope, Merise, RUP, etc.). Les différences sont au niveau des particularités, et non à celui de la philosophie générale, qui est exactement la même.
L'idée fondamentale des méthodologies documentaires est celle des solutions « centrées-document » (en anglais, « document-centric »). Cette approche considère le document comme l'unité de base de la communication entre humains, ou entre un système et un humain. Selon cette approche, on ne doit pas tenter d'éliminer les documents des systèmes d'information (comme le fait souvent, pour toutes sortes de raisons, l'informatique traditionnelle), mais plutôt les concevoir soigneusement, en toute conscience de leur rôle fondamental dans le fonctionnement du système en développement.
On peut invoquer quatre arguments pour supporter une approche centrée-document. (1) La métaphore du document est facile à comprendre pour la plupart des catégories d'utilisateurs. Le fait qu'un système exploite à fond cette métaphore tendra donc, a priori, à favoriser son acceptation et sa bonne utilisation. (2) Une grande proportion de l'information des organisations et collectivités n'est pas consignée dans des bases de données structurées (par exemple, relationnelles), mais plutôt dans des documents semi-structurés ou non structurés (par exemple, fichiers de traitement de texte). En adoptant une approche centrée-document au développement de systèmes, on peut espérer arriver à traiter une plus grande part du capital informationnel de l'organisation ou de la collectivité pour laquelle le développement s'effectue. (3) Une approche centrée-document permet une coexistence plus harmonieuse de systèmes basés papier et électroniques. (4) Comme les artefacts d'un système d'information basé sur une approche centrée-document sont des documents (numériques, mais des documents tout de même), il est plus facile de leur appliquer les traitements archivistiques classiques, lequels sont définis en termes de documents. Ceci assure à son tour la conformité avec les cadres réglementaires et légaux en vigueur pour la gestion de l'information (calendriers de conservation, accès à l'information, confidentialité, etc.).
Au Québec, les deux faits suivants plaident en faveur d'une approche centrée-document: D'une part, depuis 2001, la « Loi concernant le cadre juridique des technologies de l'information » (L.R.Q., c. C-1.1) définit le document comme tout ensemble d'information structuré, délimité et intelligible. Dans ces conditions, tout échange d'information entre un humain et une base de données est un échange de document, et un système développé autour d'une base de données gère des documents, que ses concepteurs le veuillent ou non. D'autre part, le concept de document est très présent dans la loi. À titre d'exemple, relevons que la loi que l'on appelle communément « Loi sur l'accès à l'information » s'intitule en fait la « Loi sur l'accès aux documents des organismes publics et sur la protection des renseignements personnels » (L.R.Q., c. A-2.1). Ceci s'explique: en effet, l'échange de documents est, pour la plupart des gens, l'archétype même de la transaction d'affaires. Le recours au concept de document dans la loi ne fait que refléter cette réalité.
Spécificités d'une méthodologie documentaire:
Grandes phases de la mise sur pied d'un système: les mêmes six que les méthodologies générales (voir ci-dessus).
Les principaux modèles de données utilisés pour la modélisation dans un méthodologie documentaire sont les suivants: textuel, relationnel, hypermédia et documents structurés (parfois appelés aussi information ou données semi-structurées).
Les logiciels utilisés dans les systèmes mis sur pied selon une méthodologie documentaire sont bien sûr le plus souvent de type COTS. Ils incluent notamment:
Cela, sans compter les navigateurs Web (Firefox, Internet Explorer, etc.), qui constituent maintenant de véritables interfaces universelles d'accès à l'information et aux services.