Le gouvernement donne aujourd’hui le coup d’envoi des travaux du projet VITAM, du nom de ce socle interministériel destiné à l’archivage des documents électroniques détenus par l’administration. Développé en open source, ce programme va tout d’abord concerner trois ministères particulièrement concernés par les problématiques d’archivage : la Défense, les Affaires étrangères et la Culture.
Alors que l’administration produit désormais de plus en plus de documents grâce à l’outil informatique, se pose régulièrement la question de la conservation dans le temps de toutes ces données, que ce soit pour des raisons pratiques, juridiques ou historiques. « Jusqu’ici, pour archiver ses documents numériques, l’administration centrale s’est appuyée sur des techniques de conservation classiques, taillées uniquement pour des volumes modérés. Avec la croissance exponentielle des documents créés nativement au format numérique, cette situation est de moins en moins tenable » nous explique un bon connaisseur du dossier.
En 2011, les archivistes et informaticiens des ministères de la Défense, de la Culture et des Affaires étrangères ont ainsi commencé à réfléchir à l’élaboration d’une solution commune d’archivage, qui soit réutilisable par l’ensemble des administrations. Le coup d’envoi des travaux du programme VITAM, pour « Valeurs Immatérielles Transmises aux Archives pour Mémoire », devait justement être donné cet après-midi en présence des ministres Fleur Pellerin et Thierry Mandon. L’idée ? Développer un socle open source qui pourra ensuite être peaufiné par chaque ministère, en fonction de ses besoins (simple conservation « pratique » ou obligation d’archiver sur un plus long terme des documents importants, etc.).
De premiers « éléments visibles » attendus pour la mi-2016
Le programme en question ne vise pas les infrastructures techniques – serveurs – mais la solution informatique qui les gère. Plus concrètement, il est question de mettre au point un backoffice qui « assurera des fonctions d’indexation, de gestion des métadonnées, de stockage, de pérennisation des fichiers et bien sur de recherche », nous explique l’équipe en charge du projet, composée pour l’instant de cinq personnes. « Développé en open source, le socle VITAM fournira des interfaces (ou API) ouvertes. L’objectif étant de s’intégrer le plus facilement possible avec les différents logiciels des ministères : messagerie, SIRH, applications produisant des décisions de l’administration, etc. »
Les premiers « éléments visibles » de ce socle d’archivage commun sont attendus pour l’été 2016. Différents appels d’offres devraient être lancés d’ici là pour ce programme bénéficiant, dans le cadre des investissements d’avenir, d’une enveloppe de 15 millions d’euros. Les initiateurs de VITAM affirment qu’il évitera à chaque ministère d’avoir à développer sa propre brique d’archivage, isolément, outre différentes économies portant par exemple sur les coûts de maintenance.
L’équipe en charge du projet estime à 3,3 ans la durée du retour sur investissement, si seuls ces trois ministères utilisent VITAM. Si 100 organismes publics optent par la même occasion pour cette solution, ce délai pourrait être ramené à 2,4 ans. Presque de quoi faire oublier les ratés des projets Louvois ou « Dossier médical personnel »... Il n’en demeure pas moins que ce socle a vocation à profiter à terme à l’ensemble des acteurs publics : opérateurs, établissements publics, collectivités territoriales, etc.
Commentaires (31)
#1
Je prévois une série de blagues sur le “ad VITAM eternam” ad nauseam…
" />
Je vais lire l’article maintenant.
#2
En même temps, c’est même pas dans le sous-titre alors que le nom a visiblement été choisi pour cette raison, ça donne envie de saisir la perche…
" />
#3
Ils utiliseront le plugin JUVAMIN ?
#4
J’allai justement demander si eternam etais le nom du soft de sauvegarde ^^
#5
Enfin, on se met à ne pas réinventer la roue dans la fonction publique et à développer des solutions mutualisées qui profitent à tous
" />
#6
#7
J’ai comme l’impression que VITAM a été utilisé ou bien pour éviter VTAM ( je suppose déposé) ou bien comme blague par un ancien d’IBM qui sévit dans les ministères
" />
en attentant ça se prononce pareil
#8
L’administration se dote d’une solution Open Source, que chaque ministère pourra modifier et adapter à ses besoins, et qui ne la rend pas dépendante d’un éditeur privé extérieur.
" />
" />
Y’a un piège ? On est le premier avril ? C’est presque trop beau et logique pour être vrai
Bravo et merci aux gens qui ont décidé ça en tout cas
#9
#10
Des archivistes : Ces personnes aime bien que tout soit classé de façon simple et claire en générale.
#11
#12
Sinon ma boite on vend une solution d’archivage, qui suis déjà les normes de conservation OAIS… mais bon il faut réinventer encore une fois la roue.
#13
#14
#15
En tant que professionnel du secteur, ce qui est important ce n’est pas que le soft qui crée ou gère les archives soit open source mais que les accès aux archives se fasse de manières standardisés et définis de manières ouvertes et que le stockage soit auto suffisant, c’est-à-dire que les archives soit reconstructible a partir des fichiers eux même. Maintenant l’interet du cote open source pour ce qui se passe entre les deux tient plus de la décision idéologique que réellement strategiques.
#16
notons qu’il existe déjà des solutions Open Source d’archivage :
* au moins une “vraie” : maarch
* au moins une “fausse” : Alfresco
Pourquoi vraie/fausse ? parce que si Maarch ne fait pas débat, avec un code vraiment ouvert et pas de verrou caché, coté Alfresco, il y a à redire : la version “communautaire” n’est pas à jour par rapport à la version “entreprise”, et les sociétés qui veulent proposer du service sur la version “entreprise” n’ont par contrat pas le droit d’en proposer sur la version communautaire. Bref, d’aucuns disent que c’est du fauxpen source…
(il y en a peut-être d’autres, que je ne connais pas, voir icihttp://www.open-source-guide.com/Solutions/Applications/Ged-ecm pour des choses intéressantes)
#17
Attention tu confond archivage et gestion documentaire, car dans l’archivage il y a les documents mais pas que ça, tu as aussi les DBs ou carrément le contenu d’application que tu veux decommissionner.
#18
#19
Ben ça c’est une problématique dans le choix des fournisseurs, mais bon croire que parce que si tu possèdes le code source cela te permettra de modifier et maintenir un soft c’est un peu illusoire sur lorsque l’on parle de plusieurs dizaine voir centaines de milliers de lignes de code.
D’ailleurs un vrai challenge pour les projets avec des partie open source est souvent de qualifier et certifier les compatibilités de version des différents outils entre eux. Car souvent dans ce cas qui prends le risque ?
#20
#21
Peut-être, je ne maîtrise pas ce domaine (moi, c’est plutôt la gestion des bibliothèques), mais maarch indique clairement “gestion d’archivage” http://maarch.com/nos-solutions/solution-darchivage-electronique/) . Pour alfresco, ce que j’en sais, c’est effectivement plutôt GED. C’est smile qui a mis les outils dans le même paragraphe sur son site. A tort ou à raison, je ne sais, mais du coup j’ai fusionné les 2.
#22
En fait le truc c’est que dans le cas que tu décris c’est le niveau de “personnalisation” que tu ajoutes a tes produits open source. J’ai vu plusieurs cas de solutions basées sur cette “architecture” qui tient jusqu’au moment ou le produit sous-jacent évolue d’une manière non compatible avec les personnalisation, et dans ce cas la glue à mettre pour faire tenir le tout ensemble deviens tellement grande quelle absorbe tous les effort des ressources internes et en vient a freiner l’évolution de la solution.
Pour en revenir au sujet de l’article, je pense qu’il ne faut pas forcément se focaliser sur l’outil, ici ce qui est important c’est l’information et la manière d’y accéder, donc il faut que les interfaces soit ouvertes et interopérables. Et qu’ensuite les données soit stocké de manière auto-suffisante dans un format au spécification ouvertes, pour pouvoir reconstruire un système sans avoir besoin des outils qui ont générées créées les données d’archives.
#23
Il faudra que je regarde ça plus attentivement, mais il me semble (je peut me tromper) que la solution peut être utilisé pour archiver des documents mais ne permet pas l’archivage de données structurées comme une base de données par exemple. Bon il faut que je ré-étudie le truc d’un peu plus près.
#24
Je salue cette initiative, mais s’ils comptent travailler en open-sources, ils pourraient se baser sur des “briques” existantes pour ne pas réinventer le caoutchouc pour créer leur roue ;)
#25
En fait utiliser des briques open-source ou des outils propriétaires revient au même ici, tu crées une dépendance à une entité que tu ne contrôle pas, d’un coté une communauté de l’autre à un éditeur… donc si le but c’est l’open source comme garantie de pérennité et d’indépendance il te faudrait créer une fondation pour gérer l’évolution de tes outils open sources et les forks éventuels des “briques” existantes. C’est pas une mince affaire.
#26
#27
Franchement, je ne suis pas sur que ces ministères possèdent des dizaines d’ingénieurs qu’ils peuvent dédier à l’écriture et maintenance de produit. Je te rappelle que leur métier ce n’est pas d’être éditeur de logiciel fut-il open source ou pas.
En fait ce qui me chiffonne dans cette affaire, c’est qu’ils se servent du coté open source pour dire deux choses :
malheureusement ces arguments sont fallacieux, car le dev et la maintenance sera probablement sous-traité a une boite ou consortium qui ne va faire ici que du body shopping. Ensuite tout le monde sait que le fait que ce soit open source ou non, ne change pas vraiment le cout final d’un projet.
#28
#29
Tout d’abord dans tes arguments il n’y a rien qui explique pourquoi tu as une réduction des coûts, grâce à l’open source.
Ensuite pour le développement en interne, honnêtement je en crois pas que les ministères disposent des ressources nécessaires à le faire, donc ils vont devoir prendre des prestataires externes, c’est pas dans le move d’embaucher des fonctionnaires en ce moment, et c’est normal, leur métier ce n’est pas de développer du soft.
Ensuite tu connais beaucoup de projet ou la maintenance d’un code n’est pas assuré par celui qui a écris le code…
Quand a changer de fournisseurs en pleins projet pour l’écriture des codes ça relève de la science fiction ou dans tous les cas par un surcout gigantesque.
Enfin dernier point, pour le développement d’un soft open source ou non, on va parler en années, quand pour la mise en place d’un package ou vas parler en semaines. Pour mémoire au niveau institutions européennes (je ne connais pas les chiffres pour les ministères français) le cout d’un développeur junior, c’est minimum 500 - 550 euros par jour. Donc je te laisse faire le calcul pour une équipe complète avec des seniors, des chefs de projets et tout le toutim.
#30
#31
Donc on parle bien ici d’une solution back-office, qui pour le cas d’un éditeur pourrais se vendre de différents manière, aux instances installé, à la volumétrie archivé, enfin bref on peut être très créatif la dessus. Donc je ne vois toujours pas le rapport entre: Open Source et baisse des coûts. Ici leur idée c’est la mutualisation des ressources afin de faire baisser les coûts. Et ça, ça marche vraiment, mais ça n’a rien à voir avec le fait que ton produit soit open source ou non.
Mais bon je dois être stupide, et mes clients aussi (Institutions étatiques, para-étatiques et organisitations supra-nationales), on s’embête a trouver les solutions les plus efficaces, pérennes et les moins chers possibles pour pouvoir délivrer le meilleurs services dans le meilleurs délais. Et Ho surprises et bien la solution réside quasiment toujours dans un mix de technologies closed et open. La seule couche restant a développer étant la glue pour rattacher l’ensemble et fournir les accès à la solution. Alors cette couche peut être open source oui, ça ne change pas grand chose car une directive européenne permet déjà de partager le sources entre différentes administrations, peu importe le statut du développement.
Sinon pour le changement de prestataire, tu dis que dans l’open source ça arrive tout le temps, c’est vrai quand tu parles de manière individuelles, mais avant tu me parlais de changer de fournisseur donc tout l’équipe d’un coup, et là les conséquences ne sont pas les mêmes. Il est tout de même rare de voir une société ou un groupe de personnes qui n’a rien a voir avec un projet, décide de faire un fork, comme ça déjà faire partie de l’équipe de dev actuelle.
Sinon, je n’avais pas du tout fait de recherche sur ce projet VITAM, mais rien qu’en cherchant très succinctement on trouve facilement que ça fait maintenant plus de 2 ans que le projet VITAM est démarré, on trouve facilement un PoC relatifs à l’archive seul de messages électroniques, la route est encore longue si ils veulent pouvoir mettre en place un système d’archives gérant tous types de flux électroniques.