SAIP : ... et voilà le contrat !

Posted on sam. 07 janvier 2017 in misc

Épisode 1 par ici => Aperçu de l'appli SAIP sous le capot.

Suite à ma demande d'accès aux documents administratifs sur SAIP le 13 juin, puis de ma demande d'avis CADA le 13 juillet avec une réponse de la CADA le 20 octobre, j'ai fini par obtenir l'accès aux documents souhaités ces derniers jours et je les publie ici, accompagnés de quelque notes.

Le caviardage est de l'administration après consultation de Deveryware sur le sujet.

Chronologie

  1. 21 avril 2016 expression du besoin par l'administration (ministère de l'Intérieur) sur demande du premier ministre.
  2. 12 mai 2016 devis de Deveryware
  3. 23 mai 2016 après midi session de formations des formateurs à l'outil
  4. 26 mai 2016 confirmation de la passation du marché public à Deveryware
  5. 27 mai 2016 date attendue pour la livraison du poste 1 du marché (l'application mobile + le back-office) pour test interne du ministère
  6. 9 juin 2016 date butoir pour la publication finale au grand public (dans les faits l'application a été publié le 8 juin)

Qu'apprend-on dans ces documents ?

Le contrat est bien un marché public, il a été passé sans publicité préalable et sans mise en concurrence. La procédure négociée sans publicité préalable et sans mise en concurrence est régie par l'article 35 II-I du code du code des marchés publics de 2006.

II.-Peuvent être négociés sans publicité préalable et sans mise en concurrence :

1° Les marchés et les accords-cadres conclus pour faire face à une urgence impérieuse résultant de circonstances imprévisibles pour le pouvoir adjudicateur et n'étant pas de son fait, et dont les conditions de passation ne sont pas compatibles avec les délais exigés par les procédures d'appel d'offres ou de marchés négociés avec publicité et mise en concurrence préalable, et notamment les marchés conclus pour faire face à des situations d'urgence impérieuse liées à une catastrophe technologique ou naturelle

Donc le ministère a été voir Deveryware avec une expression de besoin en leur demandant un devis, sans informer personne ni demander à des concurrents puisqu'il y avait "urgence impérieuse résultant de circonstances imprévisibles" (c'est vrai, c'est pas comme si on ne savait pas que "la menace est importante" et que l'euro de football aurait lieu en France depuis le 28 mai 2010).

On apprend le prix total :

  • de la fourniture de l'application ainsi que le back-office (poste 1) : 408 960€ TTC
  • pour l'hébergement+maintenance+assistance entre le 27 mai 2016 et le 15 juillet 2016 (poste 2.1) : 30 516€ TTC
  • le prix par 15 jours supplémentaires (dans la limite de 45 jours maximum) (poste 2.2): 7 496,70€ TTC

Vu que le poste 2.2 est limité à 45 jours supplémentaires, il y a certainement eu un autre contrat qui a suivi puisque l'application est toujours fonctionnelle.

Une partie a été sous-traitée par Deveryware (notamment certains travaux sur la partie mobile et l'interface graphique du back-office). L'équipe était composée d'un product manager (responsable du projet), d'un responsable technique , un responsable sous-traitance et geste, d'un product owner partie mobile, d'un product owner partie back-office, d'un product owner partie serveur, d'un responsable UX (Expérience utilisateur) et d'un responsable assistance client. Puis de 3 équipes :

  • équipe développement application "SAIP" gérée par le product owner Mobile avec 1 scrummaster, 4 développeurs (2 android, 2 iOS) un lead test
  • équipe développement back-office gérée par le product owner backoffice avec un scrummaster et 4 développeurs
  • équipe "serveurs" gérée par le directeur technique avec 1 architecte technique, un responsable mobile, un référent qualité logicielle, 2 référents exploitation et 4 développeurs

Ce qui nous fait une bonne vingtaine de personnes qui sont intervenues sur ce projet.

Le marché prévoit une API pour l'administration, puisqu'à terme le logiciel pour lancer les alertes devrait être disponible sur un maximum de 500 postes au niveau national. Actuellement uniquement 10 postes du COGIC (centre opérationnel de gestion interministérielle des crises) ont accès à la plateforme.

La demande de ministère concernait la création de l'application pour un maximum de plateformes mobiles, avec obligatoirement android et iOS, il est assez regrettable qu'une API publique n'ait pas été prévue pour que d'autres personnes puis intégrer ces alertes confirmées par l'État dans leur logiciel ou matériel (par exemple le mobilier urbain (un arrêt de bus) qui pourrait automatiquement prévenir d'une alerte en cours) ou plus simplement cela aurait permis de développer facilement l'application Windows Phone qui est demandée par une pétition. On notera toutefois que Deveryware doit assurer la compatibilité en cas de mise à jour du système (android ou iOS) du téléphone.

Une partie du logiciel back-office est demandé comme expressément non décompilable/non rétroingénieurable, Deveryware est chargé d'héberger ce back-office. Toutefois, le ministère envisage d'héberger lui-même la solution à terme.

Une version binaire des applications android et iOS a été remise pour la réalisation d'une analyse statique dessus.

La solution a été créée avec comme estimation d'un maximum d'utilisateur correspondant à 5% de la population française (3,3 M millions) et doit permettre de livrer l'alerte sur 200 000 téléphones sur une même zone en moins de 10 minutes.

Le code source reste la propriété de deveryware qui a le droit aller le vendre dans d'autres pays (avec autorisation nécessaire du ministère s'ils réutilisent des éléments de la propriété du ministère).

On apprend aussi que Deveryware travaille pour "plusieurs ministères" mais on ne saura pas lesquels (caviardadé), mais ce sont certainement celui de l'Intérieur pour la localisation des mobiles (Voir cette article de Owni) et celui de la Justice puisque le ministère de la Justice à recours à Deveryware pour la géolocalisation (Voir cet article du Figaro).

Deveryware a aussi accès "aux services des opérateurs de télécommunication en France et à l'étranger" et travaille aussi pour les opérateurs. "Deveryware est un prestataire spécialisé intervenant en appui des opérateurs de communications électroniques français pour agréger les données des opérateurs et proposer des traitements et représentations sophistiquées consultables et pilotables aisément".

Dans le devis de Deveryware j'ai quand même été surpris par quelque chose :

Cahier des charges VS solution de SAIP

Le dispositif décrit ne correspond pas à ce qui a été livré et c'est quand même assez problématique:

  • "La notification par push d'une alerte identifiée de façon unique" : le push c'est le serveur central qui va envoyer une information à une application, dans notre cas c'est un peu différent: c'est l'application qui va chercher l'information après avoir été avertie (par Google Cloud Messaging) que le fichier d'alerte a été modifié.
  • "signature de l'alerte par certificat SHA2" : cela n'a pas été mis en place, c'est bien le problème puisque du coup on peut pouvait (depuis la dernière version du 9 novembre ce n'est plus possible) déclencher des alertes aux zombies de façon pas trop compliquée... En revanche, ils parlent peut-être du serveur qui utilise https avec un certificat signé avec sha2 (et l'empreinte du certificat est maintenant écrit en dur (pinnée) dans l'application), en aucun cas cela ne signe une alerte.

    Et tiens, le certificat TLS du serveur d'alerte est un Wildcard de optimicdn.com...