B. D'IMPORTANTS RETARDS DANS LA RÉALISATION DU LOGICIEL CENTRAL : UNE DOUBLE RESPONSABILITÉ DE L'ADMINISTRATION ET DU PRESTATAIRE
Si l'installation des sirènes, à proprement parler, n'a pas connu un retard important, ce volet n'a pas pu être opérationnel à temps en raison des difficultés liées à la réalisation du logiciel central de commande, qui a connu un important retard, de 37 mois. Environ 1 500 sirènes installées sont aujourd'hui prêtes à être raccordées au logiciel. Le 3 mai 2017, les préfectures pilotes ont pu tester le déclenchement des sirènes pour l'essai mensuel en utilisant le logiciel, mais ce dernier n'est toujours pas déployé dans les SDIS, les préfectures et les communes.
1. Un retard de 37 mois dans la livraison du logiciel permettant le déclenchement à distance des sirènes
L'élaboration du logiciel de déclenchement, coeur du dispositif, a été confiée à Airbus Defence and Space (ex Cassidian ).
L'offre de cette société a été retenue comme étant la plus adaptée, Airbus ayant mis en avant ses nombreuses références en Amérique du Nord dans le domaine des systèmes de notification de masse pour des clients publics ( Federal Bureau of Investigation , département de la santé de la ville de New York) et privés (Citigroup, Mellon Financial, etc.).
Par ailleurs, la solution proposée par Airbus devait être commune à la France et aux Émirats Arabes Unis, qui avaient également fait appel à l'industriel pour la réalisation de leur système national d'alerte.
Le marché correspondant, d'un montant de 2,82 millions d'euros, a été notifié le 30 novembre 2011.
Le choix d' Airbus Defence and Space par la direction générale de la sécurité civile et de la gestion des crises, maître d'ouvrage du projet, n'est, a priori, pas dépourvu de pertinence ; la collaboration nouée entre cet industriel et l'État dans le cadre de la mise en place et de l'exploitation de l'infrastructure nationale partageable des transmissions (INPT) plaidait en sa faveur. Le marché excluait par ailleurs les PME et SSII de taille moyenne 25 ( * ) , en raison de la technicité importante exigée pour y répondre.
Le bon de commande relatif aux unités d'oeuvre permettant l'élaboration du logiciel fut ainsi adressée le 20 mars 2012 à l'industriel, le logiciel devant être fourni à l'administration le 21 juin 2013 (début de la phase de vérification d'aptitude au bon fonctionnement). Il n'a toutefois été finalement été livré qu'en avril 2015, avec 37 mois de retard, avec une vérification de mise en service régulier (essais préfigurant la mise en service du logiciel) effectuée à compter de septembre 2016 au lieu d'août 2013 .
L'allongement de la durée de déploiement du volet « sirènes » du SAIP a conduit à reporter l'échéance de fin de réalisation de la première vague à 2019, ce qui est, selon le ministère de l'intérieur, préjudiciable au projet tant en termes de mobilisation des acteurs qu'au regard de son coût total. Ce report conduit à un surcoût de déploiement (coûts de pilotage annuel plus importants et hausse économique sur les différents marchés) estimé à près de 2 millions d'euros sur un projet de 81,5 millions d'euros, à la charge de l'État.
Les retards dans la mise en oeuvre du volet « sirènes »
Source : ministère de l'intérieur, DISIC
2. Une double responsabilité de l'administration et du prestataire
Des torts partagés entre le prestataire et l'administration expliquent cet important retard.
Du côté d' Airbus Defence and Space , le choix de recourir à des équipes basées aux États-Unis pour le développement de l'application apparaît comme une des explications du retard. Le prestataire reconnaît également que la montée en compétence des équipes a été plus lente que prévue. De même, le projet de développement commun avec les Émirats Arabes Unis ne fut jamais lancé, et Airbus dût renoncer aux économies d'échelles qu'aurait permis un développement du logiciel vendu aux deux pays, ce qui a favorisé les retards, les équipes chargées du SAIP n'ayant pas pu le développer à partir d'un progiciel préexistant. L'équipe d'Airbus est restée mobilisée en dépit des surcoûts importants apparus au cours de l'exécution du contrat, qui ont sans doute engendré des pertes financières pour l'entreprise.
Les délais de livraison du logiciel ont également souffert des retards de validation par l'administration des dossiers d'architecture technique et fonctionnelle du projet. Selon le prestataire, une des principales difficultés rencontrées a été l'absence de doctrine d'emploi lors de la phase de conception. Alors que le contrat prévoyait cinq jours de réunions avec les services utilisateurs pour valider les fonctionnalités de l'outil, les groupes de travail se sont échelonnés de mars 2012 à janvier 2013 avec une remise en cause fin 2012 des principes de base de l'application tels que, par exemple, la définition du déclenchement d'une alerte.
La complexité des fonctionnalités de logiciel, ainsi que la gestion des droits et des profils des utilisateurs (préfectures, service départemental d'incendie et de secours (SDIS), centre opérationnel de gestion interministérielle des crises (COGIC), etc.) a nécessité une spécification dense, de plus de 1 400 pages, modifiée en cours d'exécution du contrat, rendant les adaptations difficiles pour le prestataire.
Par ailleurs, le ministère de l'intérieur a abandonné en mai 2015 la fonction qui devait permettre l'envoi de SMS Cell Broadcast dans la même zone d'alerte que celle des sirènes actionnées. L'abandon de cette fonctionnalité en cours de projet, alors même qu'elle était, à juste titre, jugée critique par le ministère de l'intérieur lui-même traduit bien le manque de préparation du projet 26 ( * ) .
Si des éléments exogènes (perte du marché émirati par Airbus, défauts d'organisation des équipes) ont contribué aux retards, une partie des difficultés aurait pu être évitée si l'administration avait davantage préparé le projet en amont et précisé ses exigences.
Ces retards et ces difficultés s'expliquent également par les effectifs particulièrement restreints affectés au projet SAIP. Ainsi, au sein de la direction générale de la sécurité civile et de la gestion des crises, le projet est suivi par cinq personnes dont une à temps plein et deux aux trois quarts, et, à la direction des systèmes d'information et de communication, par quatre personnes à temps également partiel.
Aussi, si seuls les projets informatiques d'un montant supérieur à 5 millions d'euros 27 ( * ) doivent faire l'objet d'un avis de la direction interministérielle des systèmes d'information et de communication (DINSIC), une saisine volontaire du ministère de l'intérieur de cette dernière aurait été justifiée, eu égard aux faibles effectifs dédiés en interne à ce projet et à sa complexité, même si son montant s'élevait à 2,43 millions d'euros.
Cette procédure apparaît vertueuse car elle permet aux projets concernés de bénéficier de l'expertise et de l'appui de cette direction (mesures telles que des formations ou des activités d'animation de communautés professionnelles afin de partager les meilleures pratiques) 28 ( * ) .
|
Recommandation n° 3 : pour permettre au ministère de l'intérieur de faire face aux projets informatiques d'envergure, prévoir une procédure, exigeant la formulation d'un cahier des charges précis élaboré en amont de la notification du marché et un éventuel appui de la direction interministérielle du numérique et du système d'information et de communication de l'État (DINSIC), lorsque la complexité le commande, même si le coût du projet est inférieur au seuil réglementaire. |
* 25 Les exigences spécifiées dans le règlement pour répondre au lot 1 étaient de 30 millions d'euros de chiffre d'affaires annuel minimum.
* 26 Selon les informations recueillies par votre rapporteur spécial, la possibilité de déclencher l'application smartphone SAIP depuis le logiciel pourrait être à nouveau envisagée dans le cadre d'un futur marché.
* 27 Décret n° 2011-193 du 21 février 2011 portant création d'une direction interministérielle des systèmes d'information et de communication de l'État . Ces seuils de coût ont été fixés par arrêté du 1 er juin 2011 pris pour l'application de l'article 7 du décret du 21 février 2011 précité.
* 28 L'informatique publique : quels moyens pour l'administration de demain ? , Rapport d'information n° 76 (2016-2017) de M. Michel Canevet, fait au nom de la commission des finances, déposé le 26 octobre 2016, p. 24.