L’informatique a-t-elle progressé depuis l’An 2000 ?

Souvenez-vous du scandale qu’a été le « passage à l’An 2000 », et des coûts faramineux pour la société qu’a entraîné la nécessité d’ajouter deux chiffres à une date ! (certes, l’événement était inattendu !)

La communauté informatique a dû, au moins, en tirer la leçon. Quelques doutes nous assaillent, cependant, quand nous entendons que, pour assurer la conformité aux nouvelles réglementations, la première chose à faire est d’inventorier les traitements. Les entreprises s’y mettent dare-dare, mais sans viser l’exhaustivité, car celle-ci paraît hors d’atteinte. (impression de déjà-vu)

  1. Les budgets nécessaires pour assurer la conformité au RGPD (Règlement général pour la protection des données),
  2. les amendes à venir en cas d’échec (on ne manque pas d’oiseaux de mauvais augure)…

…voilà de bons indicateurs des progrès méthodologiques réalisés ces dernières décennies et du niveau de professionnalisme atteint dans la maîtrise des systèmes d’information. Il suffira de faire les comptes. Il suffira de comparer ces sommes aux économies que l’on a cru réaliser en se débarrassant des méthodes et en rognant sur la formation.

Il faudra un peu de rigueur pour assurer la conformité et un peu de créativité pour tirer parti de la pression réglementaire. Les méthodes traditionnelles ou récentes ne suffisent pas, puisque leur horizon est celui du projet et de l’application. Notre sujet réclame une approche globale, celle de l’architecture.

Il s’agit aussi de coordonner différents points de vue :

  • juridique (l’aiguillon de la loi),
  • stratégique (l’occasion à saisir pour créer de la valeur, plutôt que d’adopter une posture défensive),
  • communication et marketing (les enjeux d’image et de confiance),
  • organisation (l’impact sur les comportements des collaborateurs et sur les processus – pas seulement une case de plus dans l’organigramme),
  • informatique (la technologie à dompter).

Cette transformation convoque, donc, toutes les spécialités de l’architecture – métier, organisation, logique, technique, physique -, placées normalement sous l’égide de l’architecture d’entreprise qui doit en assurer la cohérence.  L’architecture générale de l’entreprise est, elle-même, dans les mains de la direction générale (si ce n’est pas le cas, autant dire qu’elle ne sert à rien).

La protection des données analysée à travers le Repère Praxeme

Le schéma ci-dessus illustre cette approche. L’analyse intentionnelle révèle des exigences et orientations auxquels doivent répondre des éléments dans les autres aspects de la réalité de l’entreprise. Les flèches pointillées représentent les relations de traçabilité (ou de référence). Par exemple, des paragraphes du RGPD imposent de repérer les informations sensibles. Leur description est formalisée principalement dans l’aspect sémantique de l’entreprise, c’est-à-dire son patrimoine de connaissances. D’autres paragraphes conduisent à mettre en place des rôles et activités particulières, mais aussi à injecter la surveillance dans l’ensemble des processus. Ce travail de conception organisationnelle ressortit à l’aspect pragmatique. Les exigences de la réglementation  se projettent ainsi dans tous les aspects de l’entreprise, justifiant les dispositions à mettre en place.

Le schéma ne peut montrer qu’une synthèse de cet effort. Le travail doit être mené de façon plus détaillée, à travers des modèles précis, faute de quoi il est impossible de dominer la complexité de l’exercice. Ici, le dispositif clef est le référentiel de description de l’entreprise. 

Cet outillage est bien connu et peut s’appuyer sur des standards internationaux. Quelques compléments sont nécessaires. Les méta-données comme la sensibilité des informations, la finalité de leur collecte et leur durée de conservation s’ajoutent au méta-modèle (= la définition des éléments nécessaires à la description). Ceci peut se mettre en place rapidement. Les fonctions d’historique des données (data lineage) et d’alerte (délai de conservation dépassé) peuvent être traitées une bonne fois pour toutes par la conception logique. Les solutions de sécurité (détection des brèches…) doivent, bien sûr, être systématisées. Le reste est affaire de discipline. En travaillant de la sorte, autour du référentiel de description, l’entreprise dispose d’une description précise de ce qu’elle est et de ce qu’elle veut devenir. En cas d’évolution importante, elle n’aura pas besoin de commencer par un inventaire fastidieux, et pourra aller droit au but.

Recommandations pour les programmes de mise en conformité

Il est, néanmoins, plus probable que les projets de mise en conformité passent par des raccourcis. On dénoncera l’approche présentée ici, comme théorique – c’est le mot généralement utilisé pour exclure tout effort que l’on n’est pas prêt à consentir, effort de compréhension ou de mise en pratique. On préférera court-circuiter les aspects « métier », « abstraits » : la traçabilité sera établie directement entre les composants logiciels (à grosse maille) et les exigences de la réglementation. On donnera les habituelles justifications économiques, totalement fallacieuses : faire vite, moins cher. Le genre d’argument qui ont conduit au scandale de l’An 2000 et à d’autres gabegies.

Nous saurons bientôt si la communauté a progressé… ou si nous vivons dans un jour sans fin.

 

Pour marque-pages : Permaliens.

Les commentaires sont fermés