En juin dernier, une panne survenait dans un data center utilisé par l’Agence pour l’informatique financière de l’Etat, entraînant l’arrêt du progiciel Chorus utilisé par 35 000 fonctionnaires pour gérer les dépenses courantes de la France.

La panne d’ampleur qui a gelé pendant quatre jours le paiement des fournisseurs de l’Etat illustre bien l’importance des moyens informatiques dans la vie publique comme dans celle des entreprises et des particuliers. Sans parade immédiate, un dysfonctionnement d’ordinateur ou de serveur distant peut causer des désagréments plus ou moins importants qui vont du simple retard jusqu’aux dommages irréversibles. Même s’il est exceptionnel en terme de scénario, le « plantage de Chorus » met en évidence des erreurs que les protagonistes vont sûrement analyser pour en tirer des correctifs et des stratégies de retour à la normale. L’évènement doit également interpeller toutes les organisations dont l’activité repose partiellement ou totalement sur un système d’information résident ou distant. Le moment est en effet particulièrement opportun pour se poser la question : qu’est ce qui est prévu pour continuer ou reprendre l’activité perturbée ou interrompue.

Un enchaînement dramatique

L’arrêt brutal du progiciel Chorus (qui tourne sous logiciels SAP a-t’on appris) a été causé par un « accident matériel » qui serait survenu sur des infrastructures hébergées par Bull. Pour être précis, l’incident aurait été provoqué le 19 juin par une erreur d’intervention – erreur humaine donc – d’un sous traitant en mission dans un data center de la région d’Angers : des travaux auraient provoqué de la poussière, pollution qui aurait d’abord mis en panne le système de climatisation, ce dysfonctionnement entraînant par la suite le déclenchement du dispositif de lutte contre l’incendie. Celui-ci fonctionne par un envoi de gaz neutre sous haute pression qui appauvrit la teneur en oxygène du local et étouffe les éventuelles flammes. C’est cette projection de gaz qui aurait détérioré des disques durs dans des serveurs et provoqué l’arrêt du système. Contactée par la presse spécialisée, l’AIFE (Agence pour l’informatique financière de l’Etat qui pilote le fonctionnement et les évolutions de l’application) a reconnu que l’infrastructure de stockage avait été victime d’une panne le mercredi 19 juin à 10h15, entraînant l’indisponibilité du système cœur de Chorus à partir de 14 heures ce même jour. L’AIFE précisait même qu’une baie de stockage était endommagée, « sans possibilité de reprise des données », alors qu’une publication en ligne évoquait une détérioration simultanée de « plusieurs composants majeurs d’une baie de stockage, pourtant équipée de systèmes de disques redondants de haut niveau Raid 6» ce qui laisse sous entendre l’impossibilité de restaurer les données indisponibles. L’AIFE aurait ensuite lancé un plan de reprise d’activité (PRA) le 20 juin au matin mais le retour à la normale ne serait intervenu que le lundi suivant, après restauration des données et de multiples vérifications qui se seraient déroulées durant tout le week-end sans révéler d’anomalie.

Des conséquences diverses

L’incident sur Chorus a finalement impacté la production de 25 000 utilisateurs, l’AIFE précisant que l’application « formulaires », utilisée par 30 000 personnes, a continué à fonctionner. Le système gérant les échanges de fichiers n’étant pas tombé en panne, il a été possible de traiter la quasi totalité des flux envoyés en instance a indiqué l’AIFE tout en précisant qu’un ordre de 13 400 virements a été remis à la Banque de France pour régler les 181 millions d’euros de factures en attente depuis le 19 juin.

Cet épisode pour le moins calamiteux vient s’ajouter à la longue suite de critiques qui ont déjà émaillé la vie tumultueuse de Chorus depuis le lancement du projet en 2005. Il suffit en effet de lancer une recherche sur le web pour se faire une idée des récriminations formulées par la Cour des Comptes, les députés, les syndicats de fonctionnaires et autres controverses déjà suscitées par Chorus. Il n’en demeure pas moins que cette interruption va avoir des suites pour le prestataire hébergeur qui fournit les services d’infrastructures mais aussi de sécurité. Selon un blog spécialisé, le contrat signé par Bull mentionnerait une infrastructure « à très haute disponibilité » pour héberger Chorus, la convention précisant un taux de 99,8 % (soit environ 40 heures d’indisponibilité maximale par an). La panne en question dépasse largement cette limite et doit logiquement activer une clause de dédommagement. Bull aurait évoqué de son côté «La mise en œuvre des procédures d’urgence adéquates permettant de revenir aux conditions normales d’exploitation en moins d’une heure, les conditions d’exploitation dégradées pendant ce temps ayant pu avoir des impacts chez certains de nos clients ».

PRA ou PCA ?

Certains commentateurs font quand même remarquer que dans cette affaire il serait bon « d’améliorer le PRA » alors que d’autres estiment que « sur un tel système, un PCA semble indispensable ». Il est vrai qu’un Plan de reprise d’activité n’est pas similaire à un Plan de continuation d’activité. Dans le premier cas, il faut d’abord déterminer la meilleure stratégie pour protéger au mieux l’activité en cas de panne causée par un sinistre ou un incident, c’est à dire définir les priorités et une chronologie pour reprendre l’activité dans un délai acceptable pour l’entreprise. Cela passe par une analyse des risques et de leurs impacts, le calcul des durées critiques d’indisponibilité des différentes fonctionnalités du SI et la désignation des personnes, des services ou des prestataires habilités à intervenir pour restaurer la situation. Un PRA se prépare en prenant des mesures préventives (définition des modes et équipements de sauvegarde, prévision et définition des systèmes de secours, création de redondance système, réplication des données) puis en appliquant des mesures curatives après identification des défaillances (restauration des données, redémarrage des applications et des machines en mode provisoire ou définitif, repli sur un site de secours). Dans le second cas, il s’agit de maintenir coûte que coûte les activités essentielles. Les spécialistes scindent le PCA en deux volets : le PCO pour plan de continuité opérationnelle qui définit les impératifs de la continuité de l’activité et le PCI pour plan de continuité informatique qui détermine les modes opératoires et les moyens de continuité des fonctions du système d’information. Des réunions avec les responsables opérationnels permettent de définir les priorités et les niveaux de dégradation admissibles, puis sont déterminés des scénarios et des phasages, de même que les moyens à mobiliser. Le PCA fait ensuite l’objet de tests pour vérifier la pertinence des décisions prises et surtout leur faisabilité. Puis, il faudra le mettre régulièrement à jour.

Pour les commentateurs de l’incident Chorus, il est presque évident que l’AIFE a fait l’impasse sur le PCA en négociant avec son hébergeur et que son PRA, avec une reprise sous 4 jours, semble indiquer que l’agence est prête à subir des coûts d’indisponibilité de plusieurs dizaines de milliers de jours/hommes. Les mauvaises langues ne manqueront pas de dire que les retards de règlement des fournisseurs de l’Etat ce n’est pas grave, après tout !

encadré : Le rôle central de Chorus

(d’après économie.gouv.fr)

L’Agence pour l’informatique financière de l’Etat (AIFE) est en charge de la construction, du support et de la maintenance de l’outil informatique Chorus qui permet d’appliquer l’ensemble des dispositions de la LOLF (loi organique relative aux lois de finances), elle a pour mission de faire évoluer Chorus et de moderniser la fonction financière de l’Etat.

Le système d’information Chorus est aujourd’hui l’unique outil de tenue et de production de la comptabilité générale et budgétaire de l’Etat. Il centralise l’ensemble des recettes et des dépenses relatives au budget général, aux budgets annexes et aux comptes spéciaux. Chorus a été déployé dans tous les services de l’Etat, entre 2008 et 2011, et « exécute » l’ensemble des dépenses de tous les ministères depuis cette dernière date.

Depuis le 1er janvier 2012, toute la comptabilité de l’Etat est tenue dans Chorus par 54 000 agents de tous ministères, dont plus de 15 000 au quotidien. De ce fait, toutes les anciennes applications comptables ont été supprimées.

La mise en œuvre de cet outil informatique découle de la Loi organique relative aux lois de finances (LOLF) du 1er août 2001 qui promeut la transparence des comptes publics, une logique de performance de la gestion publique et l’amélioration de l’efficience des processus et du pilotage financier.