SAGESSE VOLUME VII WINTER 2022 – AN ARMA CANADA PUBLICATION

par Tod Chernikoff, CRM, IGP, CIP

 

Back to Sagesse 2022

 

Résumé

Les personnes qui achètent ou conçoivent des systèmes de gestion de l’information n’ont pas toujours en tête la conformité aux exigences en matière de gestion des documents et de l’information. Pour combler cette lacune, le personnel chargé de la gestion des documents et de l’information d’une entreprise doit participer dès le début au processus de cycle de vie de développement des logiciels pour s’assurer que ces systèmes gèrent adéquatement les documents et l’information tout au long de leur cycle de vie.

Introduction

Votre équipe de gestion des documents et de l’information (GDI) est un partenaire essentiel et doit participer dès les premières étapes au processus de cycle de vie de développement des logiciels (CVDL) pour s’assurer que les systèmes gèrent adéquatement l’information tout au long de leur cycle de vie. En comprenant l’importance de s’assurer que les systèmes utilisés pour traiter et gérer les biens sont créés et configurés de manière à conserver et à éliminer adéquatement les documents et l’information, vous améliorerez les capacités de votre entreprise en matière de gestion des documents et de l’information. La participation de l’équipe de la GDI est essentielle à l’élaboration et à la mise en œuvre adéquates de systèmes, aussi appelés produits, pour diverses raisons. Premièrement, elle veille à ce que les documents d’une entreprise qui sont stockés dans un système soient conservés et éliminés conformément au calendrier de conservation. Ensuite, elle s’assure que le système est en mesure d’empêcher la destruction ou la suppression des documents qui doivent être conservés à des fins légales, administratives ou d’enquête. Elle peut également aider à soutenir les caractéristiques des documents faisant autorité, conformément à la norme ISO 15489.

Il faut tenir compte de quelques points clés, d’autant plus que, quel que soit le type d’entreprise pour laquelle ou avec laquelle vous travaillez, il y aura des différences d’un processus de CVDL à l’autre. Le CVDL désigne un processus ou un cadre au sein d’une entreprise qui produit des logiciels au moyen d’un flux structuré de phases comportant des tâches définies.

Les systèmes sont habituellement élaborés et implémentés dans le cadre d’un processus axé sur les projets. Par ailleurs, le programme de GDI d’une entreprise est permanent. Il s’agit de quelque chose que les employés d’autres secteurs de l’entreprise ne comprennent peut-être pas, ce qui a également une incidence sur la façon dont les professionnels de la GDI abordent leur travail.

Dans le cadre du processus de CVDL, votre programme de GDI doit établir, maintenir et maintenir à jour, selon les besoins, un cadre permettant de fournir de l’information à jour sur les exigences et de gérer votre partie du processus d’examen. Ce processus doit être élaboré de manière à être communiqué et appliqué de la même manière par tous les membres de l’équipe de GDI. 

Il doit également permettre d’examiner les cas de systèmes incapables de gérer et d’éliminer correctement les documents et l’information, d’accorder des exceptions ou de suggérer des solutions de rechange.

Les entreprises ne possèdent pas toutes les mêmes capacités. Ce qui fonctionne pour une entreprise ne fonctionnera peut-être pas pour une autre. Préparez-vous à élaborer un processus adapté à votre situation.

Cela dit, les messages que je souhaite vous transmettre dans cet article sont les suivants : 

1. Le personnel chargé de votre programme de GDI constitue un élément essentiel du processus de CVDL et doit participer dès les premières étapes, dans le cadre de tous les projets, ne serait-ce que pour confirmer qu’aucune information n’est en jeu et que le projet peut aller de l’avant sans autre examen.
2. Il faut faire des compromis pendant le processus.
3. Les systèmes sont habituellement élaborés et implémentés dans le cadre d’un processus axé sur les projets. Par ailleurs, le programme de GDI d’une entreprise est permanent.
4. Vous devez tenir compte d’autres facteurs si vous passez d’un processus papier ou physique à un environnement numérique. Dans certains cas, cela peut être plus simple que la mise à jour de certains processus numériques.
5. Dans le cadre du processus de CVDL, votre programme de GDI doit établir, maintenir et maintenir à jour, selon les besoins, un cadre permettant de fournir de l’information à jour sur les exigences et de gérer votre partie du processus d’examen. Ce processus doit être élaboré de manière à être communiqué et appliqué de la même manière par tous les membres de l’équipe de GDI. 
6. Il doit également permettre d’examiner les cas de systèmes incapables de gérer et d’éliminer correctement les documents et l’information, d’accorder des exceptions ou de suggérer des solutions de rechange.
7. Les entreprises ne possèdent pas toutes les mêmes capacités. Ce qui fonctionne pour une entreprise ne fonctionnera peut-être pas pour une autre. Préparez-vous à élaborer un processus adapté à votre situation.

Méthodes de développement de logiciels

Les systèmes ne sont pas tous créés ou développés de la même façon. Les deux principales méthodes de développement de systèmes sont la méthode en cascade et la méthode agile.

La méthode en cascade est une méthode linéaire et séquentielle comportant des livrables établis. Selon cette méthode, les parties prenantes fournissent des exigences dès le départ et le projet doit répondre à ces exigences. Même avec la méthode en cascade, il existe différentes façons d’adapter le processus. Les deux premières colonnes de la figure 1 montrent deux parcours similaires, mais légèrement différents, et la façon dont je les compare.

Le développement agile est axé sur un processus itératif dans le cadre duquel les exigences et les solutions évoluent au fil du temps de manière collaborative grâce à des équipes inter-fonctionnelles. Cette discussion portera davantage sur la méthode en cascade, mais il est important de ne pas oublier que dans certaines entreprises, la méthode agile est la plus utilisée. Je travaille dans une entreprise où nous utilisons les deux méthodes, et le volume de projets utilisant la méthode agile augmente.

La figure 1 illustre trois méthodes de développement possibles et leur comparaison les unes aux autres. La première colonne présente la méthode dont il est question plus loin dans cet article. Je l’ai découverte dans le secteur privé. La deuxième colonne représente le cadre du cycle de vie du rendement de l’entreprise (CCVRE). J’ai utilisé cette méthode lorsque je travaillais comme consultant auprès d’un organisme gouvernemental aux États-Unis. Le CCVRE et le CVDL sont les deux formes de méthode en cascade. La troisième colonne décrit un cadre de développement agile. Dans certains cas, il existe des noms de phases, des aspects et des activités semblables d’une méthode à l’autre. Elles sont alignées pour illustrer, de la façon la plus claire possible, leurs similitudes.

CVDL	CCVRE	Cadre de la méthode agile
Création	Démarrage	Lancement
Création	Concept	Lancement
Planification	Planification	Planification
Analyse de systèmes	Analyse des besoins	Planification
Conception de systèmes	Conception	Planification
Développement de systèmes	Développement	Développement
Essai de systèmes	Essai	Développement
Acceptation par les utilisateurs	Essai	Développement
Déploiement	Implémentation	Déploiement
Clôture de projets	Exploitation et maintenance	Fermeture
	Élimination
Figure 1 Comparaison des méthodes de développement de systèmes

Expérience et prise de conscience d’un problème de déconnexion

Avant de travailler à temps plein en GDI et m’intéresser au CVDL, mes expériences ont porté sur des aspects des technologies de l’information (TI), comme la qualité et le nettoyage des données, ainsi que sur l’expérience utilisateur, l’analyse des besoins et la participation à des réunions, à titre d’observateur, au cours desquelles des cadres supérieurs effectuaient des examens et prenaient des décisions concernant des projets de TI. Ces expériences, qui datent d’une d’une vingtaine d’années, m’ont préparée pour l’avenir. Je vous recommande de rester à l’affût des possibilités de participer aux processus de votre entreprise afin d’élargir vos connaissances, vos compétences et vos aptitudes. Il pourrait s’agir d’occasions de participer à des projets visant à intégrer de nouveaux outils et de nouvelles technologies. Vous pourriez, par exemple, vous porter volontaire pour tester de nouveaux outils avant ou pendant leur déploiement, ou suivre une formation sur de nouveaux outils ou des outils qui seront possiblement utilisés.

À peu près à la même époque, il y a une vingtaine d’années, j’ai commencé à constater qu’il y avait souvent un manque de communication entre les personnes qui achetaient et construisaient des systèmes de gestion de l’information et celles qui étaient chargées de la conformité aux exigences relatives à la GDI. Maintenant, je passe une bonne partie de mon temps au travail à établir cette communication. Il ne se passe pas une journée de travail sans que j’assiste à une réunion, que je communique avec un gestionnaire de projet, un analyste-spécifications ou un membre d’un groupe commercial participant à l’un des quelque mille systèmes de l’entreprise mondiale de mon employeur. Je passe également du temps à fournir à diverses parties prenantes, tant à l’intérieur qu’à l’extérieur du service de l’information, de la formation à ce sujet.

Rôles

Dans le cadre du processus de CVDL, vous pouvez rencontrer de nombreuses personnes qui jouent différents rôles. 

Votre équipe sera dirigée par le gestionnaire de la GDI ou de la gouvernance de l’information (GI), le directeur ou un autre cadre de votre entreprise et comprendra des membres du personnel de la GDI ou du GI, selon les fonctions exécutées par l’équipe. Vous interagirez probablement, à un moment ou à un autre, avec des groupes ou des services de votre entreprise, notamment :

• un conseiller juridique ou l’avocat général; 
• le service de la conformité;
• le service de la gestion des contrats, de l’approvisionnement ou des fournisseurs; 
• les groupes commerciaux ou fonctionnels qui, dans bon nombre de cas, seront propriétaires des systèmes en cours d’élaboration, y compris leurs équipes de direction; 
• les groupes et services des technologies de l’information responsables des systèmes et de l’infrastructure;
• diverses équipes et divers comités et groupes de travail chargés de l’examen;
• divers entrepreneurs et fournisseurs;
• des utilisateurs finaux;
• des équipes d’élaboration de projets ou de développement de systèmes, y compris : 
  • des gestionnaires de projets;
  • des architectes de solutions;
  • des architectes d’entreprise;
  • des analystes-spécifications;
  • des testeurs, des formateurs;
  • des spécialistes des communications;
  • des spécialistes en gestion du changement;
• Enfin, les cadres supérieurs qui, selon toute vraisemblance, possèdent un grand pouvoir de contrôle et de financement au sein de l’entreprise.

Méthode RACI (responsable, agent comptable, consulté et informé)

Pour documenter le niveau de participation des divers groupes dans le cadre du processus de CVDL ou d’autres processus au sein des entreprises, beaucoup utilisent un tableau RACI. L’acronyme « RACI » signifie Responsable-Agent comptable-Consulté-Informé. La partie responsable est celle qui amorce et exécute la tâche. En outre, elle est chargée d’obtenir les approbations nécessaires. L’agent comptable est, en fin de compte, chargé de l’achèvement de la tâche. Il n’y a qu’un seul agent comptable par tâche. Les parties consultées sont celles à qui vous faites appel dans le cadre de la réalisation de la tâche. Une grande partie du temps attribué pour un projet est consacré aux communications bilatérales avec les parties consultées. Les parties informées sont celles qui sont tenues au courant de l’avancement du projet au moyen de communications unilatérales. À la figure 2, les éléments de la première ligne représentent diverses composantes d’une entreprise ou d’un organisme public. À gauche, vous trouverez les tâches liées à chaque phase d’élaboration d’un projet fictif. Dans cette représentation de la méthode en cascade, le programme de GDI figure à l’extrême droite. L’équipe de la GDI est informée des analyses de rentabilité des projets à l’étape de la création et consultée sur les exigences opérationnelles, etc. Dans la figure 1, la lettre « R » indique les parties chargées d’une tâche, la lettre « A » indique l’agent comptable dans le cadre d’une tâche, la lettre « C » indique les parties qui sont consultées et la lettre « I » indique les parties qui sont informées de l’avancement d’une tâche.

Si votre entreprise utilise à la fois la méthode en cascade et la méthode agile, des RACI distincts seront produits pour les différentes méthodes.

	Gestion des applications	Architecture de l’information	Entreprise	Communications	GDI
Création
Analyse de rentabilité		C / I	A / C		I
Exigences opérationnelles	C	C / I	A / C		C
Planification
Approche relative aux exigences		C	C		I
Analyse de systèmes
Exigences relatives aux systèmes	C / I	C			C
Conception de systèmes
Avant-projet	C / I	R /C / I	C	I	I
Développement de systèmes
Plan de test	I	I	I		C
Essai de systèmes
Résultats des essais	I	C / I	C / I	I	I
Acceptation par les utilisateurs
Plan de mise en œuvre	C / I	C	C / I	C / I	I
Déploiement
Transfert	I	I	I	I	I
Clôture du projet
Leçons apprises	C	C	C	C	C
Figure 2 Exemple de tableau RACI de la méthode du CVDL

Exigences de haut niveau en matière de GDI

Il est important que les membres du programme de GDI fassent connaître aux secteurs du développement et des affaires de l’entreprise quels sont les diverses exigences relatives à la GDI et les détails de chacune d’entre elles. Les systèmes devraient permettre, par exemple : 

• de préserver les documents et les renseignements nécessaires à des fins d’utilisation dans le cadre de litiges, d’enquêtes ou autre, et de les diffuser (et permettre leur fonction de préservation des documents par l’intermédiaire d’une interface de programmation d’application (API));
• d’associer les documents à des périodes de conservation et les conserver pendant ces périodes;
• de veiller à ce que les documents conservent leur intégrité, leur authenticité, leur fiabilité et leur facilité d’emploi, comme le prévoit la norme ISO 15489;
• d’éliminer les documents et l’information d’une manière qui est correctement documentée et qui les rend irrécupérables;
• de rechercher et d’extraire des documents; de fournir les paramètres et les capacités de production de rapports nécessaires;
• de contribuer à la transition des documents des anciens dépôts vers les nouveaux pour assurer une tenue à jour et une élimination appropriées.

Le programme de GDI doit également fournir des renseignements supplémentaires qui permettront aux entreprises, aux équipes de projet et aux autres intervenants de bien communiquer la façon dont ils se conformeront à ces exigences.

Éléments pouvant être exclus de la portée

Comme je l’ai mentionné précédemment, il y a des situations dans lesquelles l’équipe de GDI ne participera pas aux projets ou aux produits en cours d’élaboration ou de déploiement. Voici des exemples de types de systèmes qui sont souvent hors du champ d’application, car les données ou les documents ne sont généralement pas stockés dans ces systèmes pendant une longue période.

1. Les systèmes de communication inter-réseaux reçoivent des données, puis les transmettent immédiatement dans un autre système approprié aux fins de traitement ou de stockage dans un entrepôt de données. Le pare-feu d’une entreprise est un exemple de système de communication inter-réseau.
2. Les systèmes d’infrastructure sont conçus pour un réseau de TI qui automatise les processus opérationnels à l’échelle de l’entreprise. Les applications de productivité de Microsoft Office comme Word ou Excel sont un exemple de système d’infrastructure.
3. Les systèmes de commande d’interface sont conçus pour faciliter les communications entre les différents systèmes de données afin qu’ils puissent tout simplement se « parler ». Une interface de stockage temporaire de données (STD) est un exemple de système de commande d’interface.
4. Les systèmes de recherche sont conçus pour fournir des capacités de recherche régulières ou ponctuelles parmi les données d’autres systèmes ou celles d’autres entrepôts de données. Splunk constitue un bon exemple.
5. Les systèmes interactifs reçoivent des données aux fins d’examen, puis les transfèrent vers un autre système interactif aux fins d’examen plus approfondi ou vers un entrepôt de données si aucun examen n’est nécessaire. Les données peuvent demeurer stockées indéfiniment dans le système interactif tant qu’elles sont en cours d’examen. Un exemple de système interactif pourrait être celui utilisé par les caissiers ou les représentants du service à la clientèle d’une institution financière.

Harmonisation des processus – méthode en cascade

Comme le montre la figure 1 ci-dessus, le processus du CVDL présenté dans cet article est divisé en neuf phases distinctes disposées selon une approche linéaire et séquentielle. Vous trouverez ci-dessous une description des sections et des responsabilités fondamentales au sein d’une équipe de GDI.

Création

À l’étape de la création, l’objectif principal est de créer une circulation de l’information et d’assurer la compréhension des membres de l’équipe. Prenons l’exemple d’une équipe qui travaille à la migration d’une application de courriel sur place vers un système infonuagique plus récent, comme Outlook de la suite Microsoft 365. Elle doit comprendre les exigences, de même que les processus de GDI connexes susceptibles d’être utilisés. Par ailleurs, l’équipe de GDI, composée d’un gestionnaire de la GDI, d’analystes de la GDI et de ressources techniques, doit comprendre l’objet du processus opérationnel et du système proposé ainsi que tout besoin opérationnel connexe. Il s’agit d’un moment idéal pour envoyer les nombreuses questions et demandes de renseignements formulées par les équipes.

Planification

À l’étape de la planification, l’équipe de projet veille à ce que l’équipe de GDI participe pleinement au projet à titre de partie prenante pendant toute la durée du projet. S’il existe une certaine incohérence entre les exigences opérationnelles et celles de la GDI, comme un calendrier de conservation des documents qui ne reflète pas une exigence opérationnelle valide de conservation au-delà des exigences prévues par la loi et la réglementation, une mise à jour du calendrier peut être nécessaire et le ou les membres opérationnels de l’équipe de projet doivent collaborer avec leur service pour entamer le processus de demande de mise à jour dès que possible. Au cours de cette étape, l’équipe de GDI participe au lancement du projet et continue de s’assurer qu’elle comprend le projet et les activités à venir.

Analyse des systèmes

À l’étape de l’analyse des systèmes, l’équipe de projet documente entièrement les documents, l’information et les données dans le ou les systèmes, qui traiteront et stockeront les données. Elle intègre également les exigences relatives à la GDI aux exigences globales du ou des systèmes et à la documentation connexe. 

Ce processus peut être simplifié si, par exemple, l’équipe de GDI a créé des suppléments à la trousse de documentation des exigences opérationnelles qui fournissent des lignes directrices ou des directives donnant un aperçu détaillé des exigences mentionnées ci-dessus en lien avec les exigences de haut niveau en matière de GDI. Si vous connaissez les normes logicielles du gouvernement des États-Unis, comme la norme DoD 5015 ou les exigences universelles de gestion des documents électroniques de la NARA, voici des exemples de ce à quoi cela pourrait ressembler. 

Entre-temps, l’équipe de GDI entre davantage dans les détails des processus et exigences opérationnels, et acquiert une compréhension des documents, de l’information et des données traités par le système et commence à conseiller l’équipe de projet pour toute question de GDI ou à tout problème de conformité.

Conception de systèmes

À l’étape de la conception de systèmes, l’équipe de projet crée l’architecture technique qui comprend les outils et les méthodes nécessaires pour satisfaire aux exigences en matière de GDI. L’équipe de projet consulte également l’équipe de GDI au besoin pour répondre à toute question en suspens et crée des plans d’essais qui tiennent compte des exigences relatives à la GDI. 

À cette étape du processus d’élaboration, l’équipe de GDI continue d’examiner les renseignements relatifs au projet au fur et à mesure que la situation évolue et modifie ses conseils en conséquence. Elle contribue également à l’examen des plans d’essais et de communication.

Développement de systèmes

À l’étape de développement de systèmes, l’équipe de projet veille à ce que le ou les systèmes en cours d’élaboration comprennent les fonctionnalités et les exigences relatives à la GDI précisées dans la documentation sur les exigences relatives au système et à la conception. Au-delà de la conception, le système est correctement configuré et intégré aux autres systèmes puisqu’il a été conçu pour fonctionner de concert avec ceux-ci. 

Entre-temps, l’équipe de GDI continue de répondre aux questions et de régler les problèmes qui se présentent et prépare les renseignements ou les données nécessaires à l’étape de mise à l’essai du ou des systèmes.

Essais de systèmes

À l’étape des essais de systèmes, l’équipe de projet procède à la mise à l’essai du ou des systèmes développés, y compris les composantes et les points d’intégration liés à la GDI grâce aux renseignements, aux données et aux exigences fournies par l’équipe de GDI. Elle transmet enfin les résultats à l’équipe de GDI, qui les examine et fournit une rétroaction appropriée. À cette étape, l’équipe de GDI examine également le matériel de formation et la documentation de soutien, et formule des commentaires à leur sujet, le cas échéant.

Acceptation par les utilisateurs

À l’étape de l’acceptation par les utilisateurs, l’équipe de projet veille à ce que tous les problèmes relatifs à la GDI décelés pendant le processus de mise à l’essai ont été résolus, procède à des essais des composantes de la GDI et des points d’intégration par les utilisateurs, et règle ces problèmes à la satisfaction de l’équipe de GDI avant le déploiement. 

L’équipe de GDI détermine si les composantes et les points d’intégration de la GDI sont prêts à être déployés en fonction des résultats des essais effectués par les utilisateurs et des mesures de suivi jugées nécessaires. Elle examine le matériel de formation et la documentation de soutien liés à la GDI et fournit les mises à jour nécessaires.

Déploiement

Au moment où le ou les systèmes sont déployés, l’équipe de projet les mettent en production pour les utilisateurs finaux et commence à assurer le soutien et la maintenance continus. 

À cette étape, l’équipe de GDI assume, le cas échéant, les responsabilités liées au programme de GDI et fournit, au fil du temps, les mises à jour nécessaires à la GDI, au besoin.

Clôture

À l’étape de clôture du projet, l’équipe de projet transfère toutes les responsabilités pertinentes liées à la GDI et conserve et élimine la documentation sur le ou les systèmes, conformément au calendrier de conservation. Enfin, l’équipe de GDI fournit toute l’aide nécessaire pour résoudre les problèmes liés à la GDI et des commentaires sur la documentation relative aux leçons apprises.

Harmonisation des processus – méthode agile

Bien que cet article porte principalement sur l’harmonisation des processus selon la méthode en cascade, je profite de l’occasion qui m’est offerte pour examiner les cinq étapes et responsabilités liées aux projets selon la méthode de développement agile. 

Comme il s’agit d’une méthode itérative, elle ne suit pas une trajectoire strictement linéaire. La méthode agile est plus qu’une méthode – c’est un état d’esprit qui est défini par des valeurs, guidées par des principes, qui se manifestent par des pratiques émergentes. Ce que bon nombre de personnes voient le plus clairement dans cette méthode, c’est la façon dont les logiciels sont élaborés par sprints, de courtes périodes déterminées ou itérations cycliques au cours desquelles une quantité de travail déterminée doit être effectuée. Au sens large, le concept d’agilité renvoie aussi à l’acceptation du changement et aux communications régulières pour produire de la valeur. Cette méthode passe par la pleine collaboration de tous les membres de l’équipe, par l’apprentissage par la découverte et par l’amélioration continue. 

Les noms des étapes correspondent à leur objet. En vous fondant sur les responsabilités axées sur les livrables présentées dans cet article, vous pouvez avoir une bonne idée de ce qui se passe à chaque étape. (Voir la figure 1.)

Les étapes du lancement et de la clôture n’ont lieu qu’une seule une fois par projet, tandis que les étapes de la planification, du développement et du déploiement sont cycliques et commencent par le développement et le déploiement d’un produit minimalement viable, puis par des sprints, jusqu’au déploiement d’un produit définitif. Voici une brève description des principales responsabilités de l’équipe de projet envers l’équipe de GDI à chaque étape de la méthode de développement agile, en gardant en tête que les étapes de la planification, di développement et du déploiement se répètent de manière cyclique pendant la durée d’un projet donné.

Lancement

À l’étape du lancement, l’équipe de projet s’assure que l’équipe de GDI est tenue au courant des différents éléments et qu’elle est informée de la personne-ressource ou de l’énoncé des travaux du projet, des évaluations des fournisseurs et des outils de notation, ainsi que de la feuille de route du produit et du carnet de commandes, une liste classée par ordre des priorités énumérant les (nouvelles) caractéristiques devant être mises en œuvre dans le cadre du projet. La feuille de route du produit est un plan d’action sur la façon dont le produit (système ou solution) suit le cycle de vie du projet. La feuille de route fournit un contexte pour les tâches quotidiennes de l’équipe de projet, mais elle permet également de réagir aux changements de priorités et de ressources.

Planification

À chaque étape de planification, l’équipe de projet veille à ce que l’équipe de GDI soit tenue au courant des différents éléments et informée des exigences non fonctionnelles, du carnet de sprint (liste des livrables ou des fonctionnalités à mettre en œuvre dans le projet, le système ou le produit classé par ordre des priorités), de l’approche relative aux exigences, de l’architecture des applications, du modèle logique de données, du profilage de données et du mappage des données ainsi que des exigences opérationnelles de l’architecture axée sur le service. « L’architecture axée sur le service définit une façon de faire en sorte que les composants logiciels puissent être réutilisés et qu’ils deviennent inter-exploitables grâce à des interfaces de service. Les services utilisent des normes de l’interface commune et un modèle architectural afin d’être rapidement intégrés aux nouvelles applications. » Un exemple d’architecture axée sur le service pourrait consister à intégrer des systèmes afin qu’ils puissent se « parler » afin d’accroître leur efficacité.

Développement

À chaque étape de développement, l’équipe de projet s’assure que l’équipe de GDI est tenue au courant des différents éléments et informée de l’avant-projet, des spécifications du projet de l’architecture axée sur le service, des plans d’essais, des cas et des listes de vérification, ainsi que de la planification de la mise en œuvre et de l’état de préparation opérationnelle. L’équipe de GDI devrait également être consultée en vue d’obtenir ses commentaires sur les leçons apprises ou rétrospectives de la fin du sprint.

Déploiement

Au cours de chaque étape de déploiement, l’équipe de projet doit s’assurer que l’équipe de GDI est tenue au courant des plans de mise en œuvre de la production. 

Clôture

Alors que le projet tire à sa fin, le gestionnaire de projet et d’autres personnes chargées d’obtenir la rétroaction doivent s’assurer que l’équipe de GDI est consultée au sujet des leçons apprises et des rétrospectives de fin de projet. 

Malheureusement, cette brève description ne rend pas justice au processus et je vous incite fortement à approfondir vos connaissances à propos de cette méthode. Le Manifeste pour le développement Agile de logiciels constitue un bon point de départ. J’espère que cette explication rapide vous incitera à approfondir le sujet.

Conclusion – Commentaire sur le CVDL

Il existe des façons simples d’aborder de nombreux processus comme le CVDL. Bien que les systèmes modernes de gestion de l’information contiennent des composants matériels et logiciels complexes, si vous décortiquez le processus de développement ainsi que les composantes des communications et des relations qui y sont associées, vous verrez leurs caractéristiques :

1. Le CVDL n’est pas un processus compliqué. J’en ai appris un peu sur ce sujet grâce à mon défunt père, qui a travaillé comme ingénieur à la NASA pendant des décennies.
2. Il n’y a pas de solution unique. Cette règle s’applique aussi bien aux entreprises qu’aux systèmes.
3. Le développement de systèmes ne concerne pas exclusivement les TI. Il s’agit aussi, notamment, de la GDI, des activités de votre entreprise, du client.
4. Vous devez utiliser des normes et d’autres ressources, comme des ensembles de connaissances, des index, des pratiques exemplaires, des rapports techniques et des principes, s’il y a lieu. Il est inutile de réinventer la roue.
5. Des communications fréquentes peuvent être nécessaires à certaines étapes d’un projet donné, voire pendant les activités courantes. Les exigences en matière de conservation peuvent changer; il est donc important d’en tenir compte dans l’élaboration des systèmes.
6. Vous devez apprendre à connaître les composantes en jeu au sein de l’entreprise. Vous aurez l’occasion de rencontrer les mêmes personnes à de nombreuses occasions, sur une base continue.
7. La documentation personnalisée concernant le processus de votre entreprise peut être utile et constituer un atout pour votre équipe de GDI (lorsque la documentation est bien gérée).
8. Un suivi des projets est nécessaire, surtout dans les grandes entreprises ou dans les entreprises complexes. Les membres de votre équipe de GDI déploient de nombreux efforts en tout temps, et si vous avez la bonne information à portée de main, il sera plus facile pour vous de produire des rapports à l’attention de votre chaîne de gestion.
9. La formation axée sur les rôles, adaptée aux responsabilités du stagiaire, aide grandement. Si votre équipe de développement et vos partenaires commerciaux comprennent votre processus et vos exigences, ils seront beaucoup plus susceptibles d’être réceptifs à votre participation. Si vous attirez l’attention des personnes à l’échelon approprié, vous pourrez mieux tirer parti de votre rôle.

Finir là où nous avons commencé

Si vous ne retenez rien d’autre de cet article, terminons avec le sentiment que j’ai exprimé au début… Votre équipe de GDI est un partenaire essentiel et doit participer dès les premières étapes au processus de CVDL pour s’assurer que les systèmes gèrent adéquatement l’information tout au long de son cycle de vie.

Biographie

Tod Chernikoff est gestionnaire de documents certifié, professionnel de la gouvernance de l’information et professionnel de l’information certifié. Il possède plus de vingt-cinq ans d’expérience dans la prestation de services de gestion des documents et de l’information et de gouvernance de l’information aux entreprises et à d’autres clients. Il a occupé divers postes de portée locale, régionale et internationale au sein d’ARMA International, notamment celui de membre du conseil d’administration. Todd a reçu le prix Alan Andolsen 2014 décerné par l’ICRM en reconnaissance du mentorat exceptionnel à titre de gestionnaire de documents certifié. Il est membre de l’équipe de gestion des documents et de l’information de la Navy Federal Credit Union, où il contribue à la réalisation des activités de GDI à l’échelle mondiale. Les opinions et points de vue exprimés dans cet article sont ceux de l’auteur.