samedi 16 février 2013

Archivage et Cloud, lorsque l'analyse confond offre et moyens

Archivage et Cloud, lorsque l'analyse confond offre et moyens


Références :

SI je souscris à de nombreuses critiques de l'offre Cloud effectuées par Janus, je ne partage pas par contre toute l'analyse.

Tout d'abord, si cela n'était pas clair, je différencie de manière très importante l'offre commerciale (qu'elle soit interne ou externe) des outils qui permettent de fournir une offre Cloud. Dit autrement, on peut ne pas apprécier le principe qu'une voiture de sport roule à plus de 300 km/h, mais apprécier pour autant les performances d'un moteur, des transmissions, la qualité des pneumatiques, des freins et des équipements du type radar de dépassement ou de franchissement de ligne...
Et bien c'est exactement ce que je disais : je ne vends pas une offre Cloud pour l'archivage (elle n'existe pas selon moi), mais je suis convaincu que les composants du Cloud (son moteur, sa transmission, ses freins, ses pneus, ...) sont une opportunité indéniable pour pouvoir répondre aux problématiques de l'archivage (intermédiaire et définitif).

Je vais donc reprendre le billet de Janus point par point. Mon objectif n'est pas la polémique, mais de continuer à discuter de certains points. En effet, l'intérêt de ces réflexions libres et documentées est de déterminer plus ou moins collectivement les avantages et inconvénients de telle ou telle approche...

Mon introduction du Cloud ne voulait pas dire LA solution pour l’Archivage. Donc revenons d'abord sur l'analyse de ce qu'est le Cloud.

L'introduction de mon billet précédent n'avait pas pour objet de dire que l'archivage est tout naturellement dans le Cloud, mais de présenter "autrement" ce qu'est le Cloud selon des approches classiques, ou encore ma propre vision du Cloud. Dans un second temps seulement, j'abordais les intérêts de la technologie qui composent le Cloud pour l'archivage.

« Cela (le cloud) permet …une réduction des coûts. »

Je confirme, le Cloud est une orientation naturelle et logique dans la logique de réduction des coûts. Après la mutualisation des sites informatiques (concentration), la mutualisation des infrastructures (rationalisation), le Cloud propose d'aller au-delà, et de mutualiser et rationaliser les composants supérieurs dans les couches, à savoir la virtualisation des serveurs (déjà introduites dans la concentration et la rationalisation – IaaS –), la virtualisation des services intermédiaires (stockage, sauvegarde, réseau, répartition ou adaptation de charge – PaaS –), la virtualisation des services applicatifs (composants génériques applicatifs – DaaS, SaaS –), ceci afin de limiter autant que possible les impacts pour les "métiers" vis-à-vis des évolutions des matériels (virtualisation des couches basses), des systèmes d'exploitations et des logiciels (couches moyennes puis hautes).

Par contre, en aucun cas le Cloud ne vous offre une solution clef en main à votre métier. C'est à vous de définir votre métier, et donc de créer l'application qui répond à vos besoins. Le Cloud vous rend seulement indépendant des évolutions techniques sous-jacentes.

Le Cloud, ce n'est pas "Google Drive". Le Cloud, ce n'est pas une offre de stockage en ligne. Le Cloud dont je parle, c'est une infrastructure allant jusqu'au support de composants logiciels vous permettant d'héberger VOTRE application et VOS données. Si l'application ne répond pas à vos besoins, ce n'est pas la faute du Cloud, mais de VOTRE application.

De la même manière, une solution d'archivage qui ne répond pas à vos besoins d'archivage n'est pas une bonne solution, avec ou sans Cloud. Ne confondons donc pas les moyens des objectifs...

« la location de services nécessite un degré de confiance et de professionnalisme de la part des prestataires qui n’est pas toujours au rendez-vous »

Ceci est malheureusement applicable aussi aux offres internes… Ce n’est donc pas un argument selon moi valable.

« le service à des tiers n’est pas initialement leur cœur de métier et tous les services associés n’ont pas été conçus pour des utilisateurs à hautes exigences. »

Difficile de lire cela sans penser à des grands comptes (banques) ou systèmes ultra sensibles (militaires) utilisant les technologies Cloud (encore une fois, pas forcément les offres Cloud) pour leur propre besoins, car ces technologies ouvrent des possibilités que l’informatique classique ne couvre pas.
De plus, Janus introduit un argument certes valable mais qui contredit le point précédent :

« Sauf que vous contractez avec des mastodontes pour lesquels ce n’est pas l’habitude de négocier des clauses particulières »

Si je reconnais que les négociations ne sont pas simples mais néanmoins obligatoires, le fait qu’il reconnaisse que ce sont des « mastodontes », « techniquement au point en termes de continuité de service », cela suppose qu’ils savent aussi gérer de grosses infrastructures et les services (SLA/SLR) associés, y compris pour des clients exigeants…

Mais là, je lis enfin le point qui éclaire le billet de Janus :

« si vous avez des données personnelles à gérer, renoncez au cloud »

Et là, je dis : tout à fait d’accord ! Pour pleins de raisons… Vous ne savez pas en tant que particulier où sont stockées vos données, quelles garanties seront appliquées, quelles précautions sur la lisibilité de celle-ci (format) seront appliquées. Si sur certains points des offres peuvent rassurer (opérateurs exclusivement français par exemple, et donc législation française), ils ne répondent pas à tous les besoins liés à l’archivage. Mais en même temps, on ne parle plus alors d’archivage définitif n’est-ce pas ? Les données personnelles n’ont sans doute pas le même caractère que les archives institutionnelles… Du moins, à ce jour…


Jusqu’au chapitre « Archivage et Cloud », je parlais des offres Cloud classiques, une sorte d’introduction rapide, des éléments de langage, des définitions. Mais je ne parlais pas d’une offre pour l’archivage. Ce n’est qu’à partir de ce chapitre que j’aborde le Cloud en tant que technologie (et non comme une solution clef en main) pour l’archivage, en pointant en quoi ses composants peuvent apporter un intérêt pour l’archivage.

Quand la confusion des moyens et des objectifs conduit à une analyse biaisée

A partir d'ici, je reprendrais les éléments relatifs à l'archivage.

"Deux moments pour les archives" ?

La distinction présentée par Janus entre archive intermédiaire et définitive n'est qu'une vue de l'esprit d'un point de vue informatique. Cette approche a d’ailleurs été longuement abordée durant le colloque des Archives nationales et des Archives diplomatiques des 5 et 6 février derniers. Ce qui change, selon moi, c'est la responsabilité sur les archives, mais d'un point de vue informatique, il n'y a pas de différences fondamentales. Je n'entrerais pas dans les détails mais quelques points pour l'étayer :
  • l'archivage intermédiaire est lié au métier, certes, 
    • mais un classement métier, qu'est-ce, sinon un plan de classement différent de celui archivistique, mais un plan de classement quand même
    • mais l'archive est accédée par le métier (dans un contexte métier), mais comme l'archive est accédée par le système archivistique dans le contexte définitif. Dit autrement, un système d'information archivistique est une application métier comme une autre du point de vue informatique (en considérant le SAE et le SIA comme deux entités séparées)
  • les archives intermédiaires doivent être accédées rapidement, certes,
    • mais pourquoi refuserait-on cet accès rapide aux archives définitives ? En quoi leur statut devrait suggérer qu'elles devraient être accessibles au prix d'une douleur lancinante devant son écran, attendant patiemment des heures qu'elles arrivent... ?
Pourquoi ? Parce que quelqu'un l'a décidé ? Ou parce que c'est utile ?
Parce qu’au niveau du papier on ne pouvait pas rendre accessible via le même mode opératoire, on devrait obligatoirement faire de même pour le numérique ?

Dit autrement, si une archive est stocké dans un système répondant à la fois aux exigences de l'intermédiaire et aux exigences du définitif, pourquoi devrait-on la stocker deux fois (et donc payer deux fois pour son stockage) ? Pourquoi devrait-on ne pas offrir le confort d’accès de manière similaire ?

Je ferais néanmoins une distinction sur les archives définitives avec les archives intermédiaires :
  • Les archives définitives sont (à ma connaissance) limitées au contexte de l’État et ses composantes (y compris collectivités territoriales) et elles ont l'obligation légale d'être conservée par l'État.
  • Les archives intermédiaires sont aussi présentes dans le monde hors "public", et dans tous les cas (hormis le confidentiel défense et autres exceptions du genre), elles peuvent être stockées chez un tier-archiveur.
  • Cette distinction implique donc une distinction potentielle de localisation des archives en fonction de leur nature.
Mais, et c'est là une des nouveautés de l'archivage électronique, le temps de l'intermédiaire et du définitif ne sont plus disjoints par obligation. On peut faire une copie (conforme) et donc avoir l'objet d'archive stocké 2 fois, 1 fois en archive intermédiaire, 1 fois en archive définitive, et ce, dès la validation de l'objet numérique. Il est même plus que conseillé de faire ainsi car si on devait attendre la fin de la DUA (disons 10 ans), l'objet numérique serait obsolète (sa lisibilité serait compromise) et donc son archivage deviendrait impossible. Le fait de l'intégrer dès sa validation permet au SAE (intermédiaire ou définitif), qui gère des durées de plus de 7 ans (délai raisonnable avant de risquer une obsolescence de format), de gérer les transcodifications de format au fil des obsolescences.

Louper une obsolescence, c'est risquer la perte définitive de l'objet numérique.

La copie peut aussi être évitée si le SAE sait gérer 2 plans de classement, métier et archivistique, et sait gérer des accès multiples (métier et SIA).

« L’archivage recouvre l’archivage courant et l’archivage définitif qui n’ont pas les mêmes exigences en termes d’accès et de pérennité. Le cloud pourrait convenir pour les archives courantes en termes d’accessibilité mais certainement pas en termes de pérennité et de coûts à long terme. »

Bon, on oublie l’intermédiaire ? Mes définitions (d’informaticien) :
  • Courant : intégré nativement dans l’application métier concerné (année en cours, année n-1)
  • Intermédiaire : intégré par référencement externe dans l’application métier (via une GED par exemple en mode minimal, un SAE en mode complet)
  • Définitif : dissociation de l’application métier d’avec l’objet d’archive (via un SAE obligatoire)
Donc selon moi, le courant ne peut pas être dans le Cloud, hormis si l’application métier elle-même s’y trouve (et donc ses données).

Ensuite, rien ne permet de dire que des données stockées dans un environnement Cloud ne seront pas pérenne ou plus coûteuses. Car finalement, le Cloud sur ses outils, c’est quoi :
  • Des serveurs virtuels
  • Des réseaux virtuels
  • Des stockages virtuels
  • Des framework d’applications distribués
OK, et dans un centre informatique devant héberger de grandes volumétries, qu’aura-ton ? Les mêmes technologies ! Vos centres informatiques (du moins ceux qui sont à peu près modernes) utilisent déjà ces technologies. Pas toutes, c’est possible et même certain (les technologies Cloud commencent seulement à se répandre), mais un grand nombre (virtualisation des serveurs (VM) avec VMware ou KVM ou Xen, réseaux virtuels via VLAN, stockage virtuels via la virtualisation du stockage dans les VM ou dans l’offre stockage native, applications distribuées via les répartiteurs de charges ou autres technologies cluster). Bref, cette affirmation me semble un peu péremptoire…

Et cette affirmation ignore joyeusement que j’ai positionné mon débat dans un choix délibéré : une plate-forme implémentant le Cloud mais en privé, et dans le cas des archives publiques, un Cloud privé d’Etat. Si l’Etat n’est pas capable d’assurer la pérennité de ses propres plateformes, alors qui le pourra ? avec ou sans Cloud…

Et le coût me dira-t-on ? Et bien, sans la virtualisation (toute technologie confondue), vos coûts seront indéniablement plus élevés. Les informaticiens ne sont pas des fanas de la complication (bien au contraire, plus c’est simple, plus on aime). Hors la virtualisation, c’est complexe (vous n’imaginez pas les problèmes que cela crée). Mais la virtualisation est un mouvement d’ensemble, confirmé partout car il réduit effectivement les coûts, pour peu que l’on maîtrise celle-ci. Et jusque dans les années 2010, c’était effectivement compliqué et peu maîtrisable. Et c’est là que la technologie Cloud arrive, la vraie, pas celle que l’on vous a vendu en 2005…

« l’important est d’avoir une masse critique suffisante pour bénéficier des économies d’échelle »

Là où je suis à nouveau d’accord avec Janus, c’est sur le fait que la technologie Cloud est rentable au-delà d’un certain seuil pour atteindre la masse critique (tant en masse qu’en coût de développement). Et c’est là que je tempèrerais néanmoins ce point :
  • Les outils de technologies Cloud sont de plus en plus Open Source, et donc d’un coup réduit par nature (non nuls néanmoins, attention, Open Source ne veut pas dire gratuit)
  • La masse peut être atteinte facilement par la mutualisation (plusieurs entités allant sur la même plate-forme, mais en ne partageant pas les accès applicatifs ni les archives). Il en va de même quand vous prenez le train. Vous prenez le train ensemble, mais vous ne voyagez pas ensemble. Vous ne venez pas forcément du même lieu ni n’allez forcément à la même destination. Pas question non plus de vous marier (le mariage pour tous ok, mais pas à 300 quand même, ça ferait désordre).
  • Les développements peuvent être mutualisés, du moins jusqu’à un certain point. Il y a des parties évidemment mutualisables (par exemple, la conversion de format), et d’autres qui ne le seront jamais (le métier, les méthodes d’authentifications, …). Mais ces parties non mutualisables devront tout autant être réalisées avec ou sans Cloud…

« En ce qui concerne l’open data c’est l’accessibilité qui prime alors que l’archivage s’occupe de pérennité. »

Je ne dirais rien de plus que :
  • En intermédiaire, l’accessibilité est fondamentale pour le métier.
  • En définitif, certains dossiers sont indispensables à être accédés simplement. Pour le papier, cet accès par nature est complexe et donc n’est pas simple. Mais pour l’électronique, cette barrière tombe. Je me place bien sûr dans le cadre des objets numériques « communicables »…
  • Les données de l’Open Data, pour certaines, relèvent de données d’archives publiques (intermédiaires et voire pour certaines définitives, comme par exemple les études démographiques). Donc pourquoi cette distinction ?
Il serait temps que les archivistes arrêtent de bouder l’Open Data, mais au contraire qu’ils s’en emparent pour éviter à l’Open Data des déboires à venir, que ce soit, pour ne citer qu’eux, par un plan de classement inefficace ou par une obsolescence non maîtrisée des formats. 

Les compétences (que je reconnais et apprécie) des archivistes devraient être mises à contribution, et non pas écartées ? Mais encore faut-il que vous, les archivistes, vous tentiez de repenser votre modèle : Les archives au services des usagers, et non au service des archivistes… Et dans ce cadre, l’Open Data est une illustration de réponse, sans doute non satisfaisante aujourd’hui, mais qui est né d’un besoin, sans les archivistes. D’ailleurs, il me semble que les nouvelles orientations données à l’Open Data illustrent, pour partie, un début de prise de conscience du manque des archivistes au sein du programme…

« les métadonnées ne peuvent être trop nombreuses. A contrario les Big Data sont la collecte automatique de traces, dont la fiabilité est tout sauf avérée »

J’entends bien que par Objet numérique, ses métadonnées doivent être contrôlées, afin d’éviter de noyer l’information. Mais ceci est valable pour 1 objet. Que devient 10 métadonnées (disons de 20 octets chacune) multipliées par 100 000 milliards d’objets numériques = 20 Po octets de données. Et comment voulez-vous gérez ceci ?
  • Réponse n°1 : la technologie Big Data
Big Data n’est pas dédié à la collecte automatique de traces. C’est une technologie qui brise les barrières des bases de données classiques, tant en termes de volumétrie qu’en termes de variabilité des données.

Sur l’aspect variabilité des données, je n’ai certainement pas été suffisamment clair. Si dans un SAE intermédiaire, vous devez stocker des archives de plusieurs origines différentes, de métiers différents, pensez-vous sincèrement que le plan de classement sera totalement compatible avec une structuration fixe entre des données RH, commerciales, météorologiques… ? Bien sûr que non…

Mais dans ce cas, vous me direz on fait plusieurs bases (ou tables). OK, mais vous venez de perdre de vue un des éléments du Big Data (le NoSQL en particulier), c’est la capacité dans une même table d’avoir des champs de structuration différentes. Donc comment gérer de multiples représentations, et par exemple simultanément une représentation intermédiaire (durant la DUA) et définitive des plans de classement de manière concurrente dans une même application ?
  • Réponse n°2 : la technologie NoSQL peut vous y aider, même si ce n’est pas la seule solution. Mais comme elle vous apporte aussi la réponse aux gros volumes, et du coup une simplification de développement de votre SAE et mieux encore de votre SIA (ou des accès des applications métiers au SAE directement), elle devient pour le moins intéressante et ne doit pas être écartée aussi facilement…
Oubliez les discours commerciaux sur le Cloud et le BigData, et regardez ce que ces technologies peuvent vous apporter…

« Le classement est de la même nature que les métadonnées, des informations fiables et validées dans un cadre conceptuel ordonné »

Je ne peux qu’être d’accord. A un détail près :
  • Même le tagging apporte du sens à un plan de classement (mots-clefs). Pourquoi se priver de ces informations pour le futur ? Au même titre que l’on conserve avec précaution des documents papiers avec les ratures car celles-ci nous renseignent parfois plus que le contenu du document final lui-même, ces tags peuvent apporter du sens plus tard, surtout si ceux-ci sont issus de l’auteur ou de la personne – métier – ayant traité le dossier.
  • Il peut y avoir plusieurs plans de classement. Que ce soit de manière provisoire (une exposition, un travail de recherche particulier, un plan de classement métier à objectif limité dans le temps simultanément à un plan de classement archivistique à visée plus long terme) ou de manière définitive (deux versements distincts ayant en commun un même objet numérique classé dans deux contextes différents).

« Ressources de calcul »

L’article pointé par Janus est excellent, mais à mon sens est passé en partie à côté de certains éléments. 

Tout d’abord, le point relevé par Janus sur le transit de manière fiable par le réseau est un faux problème. Si le transfert ne pouvait pas être fiable, alors je m’inquièterais sérieusement de vos données bancaires échangées par vous (achat en ligne), par votre banque (échanges entre les banques), ainsi que pour nos armées (échanges de données sur théâtre d’opération). Donc, si les échanges ne sont pas fiables, c’est que le protocole utilisé ne l’était pas. Ce n’est pas la faute du Cloud. Enlevez le Cloud, où se situe votre centre informatique ? A côté de votre utilisateur (bureautique), de votre application métier ? Quand bien même, est-ce que les liens ne se feraient pas par le réseau ? Conclusion, ce n’est pas un problème propre au Cloud.

A l’exception néanmoins d’un point, je me répète, je parle de Cloud privé (et même d’Etat), et non pas d’une offre public. Ce qui veut dire que ce Cloud sera sécurisé, protégé, et pour le transfert, je vous recommanderais – très fortement – d’utiliser des protocoles à la fois sécurisés et fiables. Dit autrement, oubliez le FTP ou le http (fiabilité, voir sécurité).

Pour la sémantisation des métadonnées, n’ayant pas accès à la thèse citée, je note néanmoins d’abord qu’elle date de 1999, et qu’en 14 ans la technologie a évolué grandement. Cette technologie n’est certes pas parfaite, mais elle s’améliore tous les jours.

Il ne s’agit pas de données pour faire des recherches à la « Google », mais, sur la base de mots-clefs importants, d’obtenir un classement automatisé sur la base d’un référentiel métier existant. La sémantisation selon moi peut permettre de compléter des métadonnées selon un axe maîtrisé, mais aussi de considérer des versements en vrac (hélas) qui ne disposent d’aucune métadonnée et que l’on doit pour autant prendre en compte. L’idée n’est pas d’obtenir un résultat parfait (du moins en l’état de la technologie à ce jour), mais de faciliter le travail des archivistes. Et qui sait, dans certains cas, elle peut même permettre un classement de qualité, pour peu que la sémantisation soit poussée à ses limites, quand elle est associée à un référentiel clair, construit par le métier avec l’aide de l’archiviste. Dit autrement, pour que cela fonctionne, il faut que l’archiviste rencontre le métier bien avant que les objets numériques ne soient créés, pour leur donner un cadre autant que possible.

Et encore une fois, je parle de Cloud pour sa technologie, non pas pour une offre en particulier. Dit autrement, je parle du moteur, des pneus, des amortisseurs, pas de la voiture que l’on veut me vendre à tout prix…

C’est long ! C’est long ! Hélas oui, mais le sujet est un peu complexe

Je ne suis pas un « geek », mais je regarde les outils que j’ai à ma disposition pour me permettre de répondre à des besoins concrets d’archivistes. Je ne travaille pas isolé dans ma tour numérique, faisant joujou avec de la technologie, j’envisage des solutions innovantes pour répondre à des contraintes extrêmes. 

En effet, selon moi, l’archivage électronique, notamment pour des durées de plus de 10 ans, pousse les limites informatiques au-delà des considérations courantes des informaticiens. Ce sujet remet en cause quasiment tous les acquis (connaissances, expériences) de l’informatique. Et l’expérience des archivistes en la matière est une source inépuisable de questionnement pour un informaticien qui ne cherche pas à vendre une solution, mais qui tente de proposer pas à pas des possibilités de réponses, évolutives dans le temps et sur la masse, et prenant en compte les besoins métiers des archivistes. 

Et je finirais par une spéciale dédicace aux informaticiens : pensez-vous que vous pourriez faire un logiciel de comptabilité sans l’aide d’un comptable ? Et bien, il en est de même pour l’archivage…

1 commentaire:

  1. Merci pour ce tutoriel simple, clair et efficace, j’ai pu grâce à vous, créer mon projet que je galérais à créer depuis des semaines !

    RépondreSupprimer