Réflexions à partir d’un article du Monde du 29-05-2018 : « Application SAIP : deux ans de couacs et des responsabilités partagées » par Perrine Signoret, Morgane Tual et William Audureau
Sous-titre de l’article du Monde : Mise en place à la veille de l’Euro 2016 en France, ce service d’alerte géolocalisée en cas d’attentat a cumulé les ratés. Ceux-ci n’ont pas toujours été d’ordre technique.
En résumé
L’échec de l’application SAIP qui devait servir à prévenir les Français en cas d’attaque terroriste nous rappelle 3 points clefs qu’il ne faut jamais oublier dans un projet applicatif en entreprise sous peine de sanction pouvant aller jusqu’à la mort du projet : l’analyse approfondie du contexte, la prise en compte dans la conception de l’application de son interaction avec l’organisation et les processus, l’impact négatif éventuellement fatal d’un planning annoncé « serré » ou « ambitieux » dès le début du projet.
Une application mal née
Il est assez exceptionnel de pouvoir parler d’une application informatique qui concerne tous les français sans exception (équipés d’un smartphone) : Parcours Sup dont on parle beaucoup ne concerne que les bacheliers (et leurs parents…), l’application des impôts en ligne n’intéresse que ceux qui en paye…
L’application SAIP (système d’alerte et d’information des populations) était censée prévenir les utilisateurs de smartphone d’une menace à proximité pour leur sécurité de type prise d’otages, attaque terroriste. Elle a été lancée le 8 juin 2016 à la veille de l’Euro de football qui avait lieu en France et a été arrêtée le 1er juin 2018, deux ans après son lancement. Lors des questions au gouvernement le mardi 29 mai 2018, Gérard Collomb avait déclaré : « Cette application n’a en fait jamais marché. »
Je vous renvoie à l’article du Monde pour prendre connaissance de la litanie des ratés de cette application y compris de relai de canulars mais un seul exemple suffira ici : Lors de la tuerie de Nice du 14 juillet 2016 un mois après sa mise en service, il a fallu attendre deux heures pour que l’application envoie une alerte…
Voilà donc une application qui a coûté entre 300 et 400 k€, qui n’a quasiment jamais fonctionné correctement (en termes de service rendu aux français) et qui est arrêtée deux ans après sa mise en service. Pourtant son objectif était louable (protéger les personnes en France) et la période a malheureusement été « favorable » à son utilisation avec toute cette série régulière d’attaques que la France a subi pendant ces deux ans.
Il est intéressant de voir si on peut tirer de cet échec quelques enseignements sur la méthodologie de projet, enseignements à appliquer dans nos projets d’entreprise, moins universels mais dont la réussite est tout aussi importante. Je n’ai pas du tout participé à ce projet SAIP, ni de près ni de loin, je n’irai pas dans le détail car je ne le connais pas mais mon expérience en méthodologie me donne une grille de lecture que je partage avec vous ici.
Je vois trois enseignements à tirer :
L’analyse du contexte est fondamentale
Après une phase de réflexion initiale informelle (*) au cours de laquelle nait l’idée du projet, commence le projet proprement dit et celui-ci débute par une phase de cadrage : Que veut-on faire ? Comment ? Avec qui ? Pour quand ? Pour combien ?
Dans cette phase cruciale pour la réussite ou l’échec futur du projet (alors qu’aucune action de conception ou réalisation n’a encore eu lieu), il ne faut pas se précipiter à répondre aux questions ci-dessus. Il est fondamental d’étudier très complètement le contexte du projet et de le décrire par écrit pour le partager avec les parties prenantes. Parce que ces éléments de contexte peuvent remettre en cause le bien-fondé du projet et amener à réorienter le projet avant même qu’il soit vraiment lancé ou même à ne pas le lancer.
Dans le cas de l’application SAIP, des éléments importants du contexte sont l’émotion et l’inquiétude de la population française à la suite d’une série d’actes terroristes. Il en résulte une pression qui s’exerce sur l’état pour « faire quelque chose ». Les alternatives concurrentes doivent aussi être étudiées. Or, il existait déjà des « solutions » comme le Safety Check de Facebook. Ce dispositif, dont l’idée remonte à la catastrophe de Fukushima (2011) et aux attentats du marathon de Boston (2013) était opérationnel depuis octobre 2014 et initialement dévolu aux catastrophes naturelles. Mais il avait été activé lors des tristes attentats de novembre 2015, à l’initiative de Facebook et pour la première fois dans une situation de terrorisme. Il aurait fallu étudier également Tweeter, les solutions à base de sms comme le font d’autres pays et probablement d’autres solutions encore.
Cette analyse de contexte a-t-elle été faite correctement ? J’en doute car elle aurait dû mentionner que le soir du 13 novembre 2015, 4,1 millions de Français ont cliqué sur le Safety Check et ont diffusé l’information à 360 millions d’internautes (chiffres Facebook). Face à cette puissance et cette efficacité, que pouvait-on alors attendre d’une application qui devrait être téléchargée volontairement par avance et fonctionner en permanence en arrière-plan. D’ailleurs, il n’y a eu que 900 000 téléchargements alors qu’il était estimé qu’il fallait 5 millions d’utilisateurs pour atteindre la « masse critique » permettant d’alerter suffisamment de gens d’un danger potentiel dans une zone donnée, le « bouche à oreille » prenant alors le relai pour informer au-delà du cercle des personnes dotées de l’application.
Interaction Application – Organisation – Processus
Le deuxième enseignement pour moi est qu’il ne faut jamais perdre de vue qu’une application ne se conçoit pas « seule ». Même hyper bien conçue et ultra performante, une application s’inscrit dans une organisation et dans des processus. Si l’organisation et les processus n’ont pas été adaptés à l’existence de l’application (car auparavant, ils existaient sans application), celle-ci peut perdre une grande partie de son efficacité.
Dans le cas de l’application SAIP, cet aspect a sûrement été très mal évalué. Il faut dire qu’il est complexe et probablement infiniment plus complexe qu’une simple application de smartphone comme SAIP. Les acteurs concernés sont nombreux : la police, la gendarmerie, les autorités locales, le gouvernement et une partie de son administration… Quant aux processus, n’en parlons pas quand on voit le côté kafkaïen auquel est confronté le simple citoyen dans de banales démarches administratives.
Nombre des dysfonctionnements signalés de l’application SAIP sont en fait liés à ces processus et à cette organisation. Par exemple, lors de l’attaque de militaires au Louvre (février 2017), le processus s’est égaré en chemin et n’a jamais conduit à appuyer sur le bouton pour lancer l’alerte.
Dans l’entreprise, on voit trop souvent des situations où la direction lance un projet applicatif pour pallier un dysfonctionnement ou tout au moins, un fonctionnement non optimum… C’est souvent mettre un emplâtre sur une jambe de bois et je connais nombre de projets informatiques ayant eu le sort de SAIP parce que l’on n’a pas voulu prendre en compte en amont ces aspects d’organisation et de processus, toujours infiniment plus complexes à gérer car il y a de l’humain derrière…
Une application plaquée sans réflexion approfondie sur une organisation existante et des processus déjà rôdés est vouée à l’échec. La prise en compte de cette dimension dans la partie opérationnelle d’un projet s’appelle communément la « conduite du changement ».
Planning et pression
Enfin, le dernier enseignement est lié à l’impact planning. L’article du Monde à l’origine de cette réflexion mentionne :
L’application a dû être réalisée en deux mois, avec une date butoir ferme pour sa mise en place : celle du 8 juin, deux jours avant le début de l’Euro 2016 de football .
On comprend indirectement que le timing était serré. Rien n’est gratuit et à l’arrivée, un timing serré se paye toujours cash.
J’ai coutume de dire que lorsqu’un projet démarre et que l’on déclare à son sujet « le planning est serré » ou pire « le planning est ambitieux », le projet sera en retard systématiquement, je ne connais aucune exception. Et si une date de démarrage impérative est associée au projet, alors c’est la qualité du produit développé qui sera affectée.
Il est d’ailleurs curieux que les directions d’entreprise n’aient pas compris cela avec le temps. Il ne suffit pas que le patron impose ses exigences pour que les difficultés naturellement inhérentes à un projet soient résolues par enchantement. Si les personnes à même de concevoir et mener le projet estiment que l’objectif est « ambitieux » (euphémisme politiquement correct de « irréaliste »), même si elles sont prêtes à mouiller le maillot, la nature profonde des choses finira par s’imposer et le projet sera en retard malgré toutes les mesures correctives qui auront été prises au fur et à mesure (le fameux tuilage) ou bien le produit livré sera de piètre qualité et c’est pendant la phase de démarrage de la production qu’on ramassera les pots cassés (dans le meilleur des cas, sinon il finira comme SAIP). Le charisme du patron qui aura imposé ses vues est malheureusement inopérant sur un planning de projet. Ce charisme peut fonctionner sur bien des sujets mais pas sur un planning.
Conclusions
- Analysez très finement et profondément le contexte de vos projets
- Prenez en compte très en amont l’organisation et ses processus dans la conception de vos applications
- Refusez les plannings qualifiés d’« ambitieux» par ceux qui savent
Quant à Facebook, il a fait évoluer son Safety Check qui ne dépend plus de la direction de Facebook pour être activé mais de la communauté des utilisateurs. Pour en savoir plus : https://www.facebook.com/crisisresponse/
(*) On peut appeler cette phase « avant-projet » mais il ne faut pas confondre avec les avant-projets d’ingénierie ou d’architecture qui, dans un processus très formalisé qui leur est propre, sont déjà des projets à part entière.