lcpdn.github.io

Moi je pense que les brillants esprits qui gèrent les questions de sécurité civile sont des gens compétents. Et qu’ils sont bien entourés. Alors je pense qu’en fait, ils n’ont jamais voulu sortir une Application SAIP. Moi je pense qu’eux voulaient une API pour des applications, mais que les détours d’une administration complexe et d’une dyslexie sournoise ont perfidement modifié le souhait de nos responsables pour finir par sortir la chose qu’est l’application SAIP.

En fait, si on réfléchit, une API était le choix le plus pertinent de la part de nos responsables. Alors, pour ceux qui ne sont pas des techy, une API, finalement, c’est un service normalisé. L’article de Wikipedia est assez clair et je n’oserai pas paraphraser ce puit de connaissance.

A mon sens, l’Etat pourrait (devrait ?) pousser le concept d’une API. Comme dans la plupart des API, on aurait deux moyens d’utilisation: POST (y placer des données) et GET (en recevoir des données). Prenons deux cas pas si improbables que cela:

• D’abord prenons le cas le plus simple: une alerte déclenchée par le COGIC (vous savez, ce truc à Paris qui gère les crises à une échelle nationale). Suite à un évènement X, le COGIC décide donc de déclencher une alerte sur un territoire donné. L’officier de permanence va pouvoir utiliser son logiciel préféré et y passer les paramètres de l’alerte. Le logiciel en question va alors pousser dans le système informatique, via l’API en mode POST, l’alerte en question. A ce niveau là, l’alerte est simplement enregistrée en base. Ensuite, une fois l’alerte en base, des logiciels vont, via l’API (en mode GET si vous suivez bien) recevoir cette alerte. Il peut s’agir d’un logiciel de gestion des sirènes antiques, du système d’alerte via Cell-Broadcasting des opérateurs, de l’application mobile SAIP (lol), des applications d’alertes internes des pouvoirs publics, etc… L’intérêt étant, qu’une API peut aussi être accessible en lecture (le GET), à tout le monde. Citoyens, développeurs, entreprises, etc. Imaginons un peu cette API intégrée à Waze et aux GPS connectés, on pourrait dévier tout le trafic d’une zone à risque immédiatement. Connectée aux applications mobiles des gros éditeurs (de Candy Crush à LeMonde.fr) on pourrait faire apparaître des notifications sur des Smartphones de gens qui n’auraient pas téléchargé l’application SAIP. Connectée aux éditeurs de réseaux sociaux, on pourrait immédiatement diffuser une alerte multi-canaux et déclencher des fonctionnalités comme le Facebook Safety Check… Bref, il n’y aurait de limites aux applications que notre imagination. Par exemple, j’ai du reverser l’appli SAIP pour avoir un ersatz d’API. J’ai mis en place un système DIY chez moi (dans le Gers), où la proximité d’une usine et la faillite du système d’alerte (qui sonne tous les midis sans que personne ne sache comment éteindre la sirène, le corollaire étant que personne ne sait comment l’allumer) m’a incité à avoir “mon mien” (même si j’avoue, c’était bien plus pour le fun de le faire que pour l’avoir). Quand une alerte est poussée sur l’appli SAIP et concerne mon village du Gers, ça fait clignoter mes ampoules Philipps Hue en rouge. Accessoirement, j’en ai fait un compte Twitter qui tweete toute nouvelle alerte: @SAIP_Officieux.

• Prenons maintenant un cas plus complexe, celui d’une alerte décidée au niveau local (oui, en France, le maire peut déclencher une alerte, le préfet le peut, etc.). Il est donc complexe de fournir un système d’alerte qui soit compatible avec notre système administratif peu souple. Il se murmure que ce serait notre système administratif qui bloquerait la mise en place du Cell-Broadcasting. Avec un système d’API, il serait on ne peut plus simple de gérer les pouvoirs d’accès des différents niveaux (Maires, Préfets, COGIC, etc.) tout en laissant la possibilité d’intégrer le déclenchement de l’alerte dans des SI déjà existants. Si un maire décide de pousser une alerte, il peut alors utiliser son logiciel fourni par l’administration, ou l’interface web fournie ou le logiciel développé par une entreprise tierce (ce qui est cool, c’est qu’en plus, ça crée une saine concurrence et donc des produits sympas). En fait, le logiciel utilisé importe peu, puisque seule la méthode POST de l’API compte 9in-fine*. Si le maire a le pouvoir, il peut pousser une alerte qui soit sur son territoire. L’alerte peut être modifiée ou approuvée (ou se voir appliquer le process que l’administration préfère) par d’autres intervenants (préfectures, ministères, etc.) selon une politique fine de gestion de droits. Mais en attendant, une fois dans le système, elle peut être lue par le système d’alerte aux populations qui peut alors déclencher sur la zone indiquée l’alerte (Cellbroadcast, sirènes, Pigeons, etc.).

Alors maintenant qu’on a aperçu les capacités d’une API en termes d’alerte, on pourrait se demander, mais combien ça coûte ? A court terme, un peu. Des consultants pour normaliser une API (allez, disons 8 hommes.mois de consultants experts, soit près de 100000 euros). Il faut ensuite implémenter l’API (allez, disons 15 hommes.mois soit près de 150.000 euros). Ensuite, un SI qui puisse supporter l’API en question, et il doit se trouver des serveurs pas trop cher et déjà administrés dans l’administration, on peut considérer ces coûts comme négligeables (et ça serait sûrement plus résilient que l’application SAIP, qui au-delà de dysfonctionnement majeur fait héberger des données régaliennes sur un CDN exotique: https://3718fa66e6.optimicdn.com/alert_list.txt. Mais combien ça rapporterait ? Enormément. Déjà parce que les citoyens auraient accès aux alertes sur tout type de plate-forme. Ensuite, parce que les entreprises intervenant sur des marchés publics de logiciels pour l’administration auraient un marché abordable en termes techniques. La concurrence qui en résulterait permettrait de réduire à long termes les coûts pour l’état (ce qui n’est surement pas dans l’intérêt de grosses firmes intervenant à la fois comme prestataires et comme… consultants). En plus, ça permettrait d’éviter aux citoyens d’avoir à faire du reverse-engineering d’un système payé par les impôts.

Bref, une API publique d’accès, ce serait le bien. Il ne s’agit pas d’une lubie technique de techniciens, mais bien une réelle stratégie politique. Et je ne doute pas que l’Etat finisse par y venir, après tout, ce ne serait que continuité de la politique d’Open Data en même temps qu’une décision pleine de sagesse. Et je ne doute pas que l’Etat fasse preuve de sagesse.

PS: Allez, Hint, si le concept d’API vous dépasse, y a des ressources faciles ici: https://www.youtube.com/watch?v=D_XFUE1GeWk

PPS: Si vous voulez échanger sur le sujet, n’hésitez pas à me pinger sur Twitter; @patrikryann

Disclaimer: Evidemment, ce billet ne reflète que mon opinion personnelle et aucunement celle des diverses organisations auxquelles je peux être affilié.