J'ai participé à un grand projet que celui de la Gestion Electronique de Document (GED) ou plus précisemment la Gestion Electronique d'Informations et de Documents Existants (GEIDE) qui s'apparente plus à de l'archivage de documents numériques qu'à de la gestion de contenu. En effet, le projet du Ministère est de stocker plus de 2 Peta Octets de documents (2 000 To ou 2 millions de Giga Octets), soit plus de 200 milliards de documents (environ 10 Ko par document).

 

Ce projet fut confié à mon équipe en 2004 avec l‘aide de deux analystes dont l'excellent chef de projet fonctionnel, M Vincent Castella. IBM a également grandement participé à nos études.

 

L’administration avait fait le choix d’un logiciel de GEIDE propriétaire en début 2002.

 

Au fil de nos études, il est apparu que ce logiciel avait un certain nombre de limitations, tous comme ses concurrents progiciels. Parmi ces problèmes, je peux citer :

• Une limitation concernant l’espace de stockage en termes de taille d’espace disque : l’ensemble des logiciels de GEIDE ont été conçus dans les années 90 où le stockage ne dépassait pas le Tera Octet (un facteur 1000 est obligatoire pour les besoins du Ministère).

• Une limitation concernant le stockage en termes de nombre de documents contenus dans un espace disque : du fait de la limitation au Tera Octet d’une part, et d’autre part que les années 90 imposaient l’usage du 32 bits, le nombre de document était donc limité à environ quelques milliards d’unités (un facteur 1000 supplémentaire est obligatoire pour les besoins du Ministère).

• Une grande faiblesse sur la réplication des documents entre deux sites : dans les années 90, la sécurité des données pouvait être garantie soit par le biais de sauvegarde sur bandes, soit par la réplication on-line de documents selon des mécanismes lents. Malheureusement, compte tenu de la masse de documents à traiter aujourd’hui (notre estimation est de l’ordre de 1 million de document par heure en période de pointe), les méthodes des années 90 ne sont pas compatibles avec ces données (la limitation de la réplication constatée aujourd’hui est de l’ordre de 4000 documents à l’heure soit un facteur 1000 à nouveau pour les performances attendues et les capacités de sauvegarde sur bandes d’autant de documents dépassent les capacités actuelles des moyens de sauvegarde).

 

De plus, nous avons également été confrontés à un problème en ce qui concerne le transfert des fichiers. En effet, pour obtenir le débit de un million de document par heure, cela signifie que près de 100 000 fichiers doivent arriver par transfert de fichier toute les heures (chaque fichier contenant environ 10 documents).Hors les progiciels de transferts de fichiers sécurisés ne permettent pas a priori d’atteindre de tels débits.

• FTP n’est pas sécurisé ni en terme de confidentialité, ni en terme de garantie du transfert.

• SFTP, son pendant sous SSH, répond certes au critère de confidentialité et de garantie de transfert mais ne permet pas de suivre l’état d’un transfert, d’effectuer sa reprise, son suivi, le déclenchement d’opération pré ou post réception, tout comme le font les moniteurs de transferts de fichiers tels que CFT.

 

Face à ces deux problèmes, j’ai décidé de développer deux systèmes, proche en terme de conception bien que différents quant à leur usage, entièrement en JAVA (1.5) et j’ai en projet de développer un troisième opus, déduit du premier et spécifique à la gestion de l’archivage légal des emails ou courriels :

• OpenLSD : logiciel de GEIDE : Open Legacy Storage Document

• OpenLSM : GEIDE pour Messagerie : Open Storage Mail

• OpenR66 : logiciel de transfert de fichier avec monitoring : Open Route 66