anchor.diff:  Le choix technologique initial des services API étaient basés sur link::http://loopback.io/[LoopBack] et link::https://www.mongodb.com/fr[MongoDB].
   Après moults difficultés et frustrations, l'équipe s'est recentrée sur le duo link::https://expressjs.com/[Express] et link::https://www.postgresql.org/[PostgreSQL].
   
  +L'équipe API met à disposition plusieurs modules Node
  +
  +[horizontal]
  +Succès::
  +  * Une bonne qualité de code ;
  +  * Intégration continue quasi systématique ;
  +  * Présence de tests d'intégration à défaut de pouvoir tester unitairement certains aspects métier.
  +
  +Frictions::
  +  * La découverte des modules est peu évidente — certains sont dans un _namespace_ GitLab différent ;
  +  * Les README sont minimalistes ou inexistants.
  +
  +Opportunités::
  +  * Harmoniser les scripts npm — `npm start` pour démarrer le service, `npm run build` pour produire les artéfacts, `npm test` pour lancer les tests, `npm run dev` pour démarrer le service en mode développement (et redémarrer en cas de changement avec `nodemon`, par exemple) ;
  +  * Systématiser des vérifications lors de l'intégration continue (`npm outdated`, link::https://npmjs.com/npm-check[npm-check], link::https://npmjs.com/snyk[snyk], link::https://npmjs.com/david[david]) ;
  +  * Héberger les modules Node sur un registre privé auto-hébergé pour faciliter le suivi semver des dépendances — ainsi que la consommation de librairies côté client (notamment pour le parsing des _steps_ ou de la grille de programme) ;
  +  * Basculer vers `node@8` et `npm@5` lorsqu'elle passe en LTS afin de bénéficier du `package-lock.json` et de l'installation déterministe ;
  +  * Systématiser le cours à des fichiers README répondant à des besoins élémentaires — périmètre fonction et exemples d'utilisation, d'installation.
  +
   > On veut réduire le temps de mise en production.
   
   Il existe une dizaine de web services avec comme objectif de distribuer la donnée au plus de monde possible au sein de _Radio France_.
  -Les services sont déployés 5 à 10 fois par semaine avec link::http://capistranorb.com/[Capistrano] et servent _100 millions_ de requêtes par jour avec un _uptime_ de 100%.
  +
  +Les services sont déployés 5 à 10 fois par semaine avec link::http://capistranorb.com/[Capistrano], tandis que le _provisioning_ et l'instantiation sont effectués avec link::https://www.terraform.io/[Terraform] et link::https://puppet.com/[Puppet].
  +L'infrastructure gère environ _100 millions_ de requêtes par jour avec un _uptime_ de 100%.
   
   > On veut être résilient à tout type de pannes.
   
  
positive.code: ** Mobile natif
  ** Direction du numérique
  
  === mercredi 12 juillet
  
  * Restitution de l'audit
  * Rencontre entre la _direction du numérique_ et  link::https://www.etalab.gouv.fr/[Etalab]
  
  ## Observation et conseils
  
  
negative.code: [horizontal]
  Succès::
  
    * Le SDK API est adopté par toutes les équipes chaînes.
  
  Frictions::
  
    * L'empilement de couches de gestion de données rend le débogage complexe et coûteux en temps ;
    * L'adresse de la documentation n'est pas connue et le ticket d'entrée est élevé — on utilise le SDK et les composants PHP en guide de doc.
  
  > La recherche, c'est encore un autre format.
  
  Chaque chaîne gère leur _front-end_ selon les affinités et compétences en présence.
  Nos discussions ont fait émerger un problème commun concernant la gestion du code JavaScript côté client.
  Chaque site de chaîne a son processus de build, ses outils, ses habitudes, ses façons de faire le JavaScript front-end.
  Ceci se traduit naturellement en beaucoup de travail dupliqué et difficilement réutilisé.
  
  > Le _front-end_, c'est le cœur de la problématique.
  
  Un conseil ici serait d'avoir une équipe transverse spécifique sur à sujets, de la même manière qu'il existe une équipe transverse sur le framework PHP qui interroge l'API interne.
  Il existe l'*équipe cockpit* qui produit des composants transverses comme le _player multimédia_.
  Notre compréhension à ce stade est que cette équipe ne fait que créer et maintenir quelques composants front-end réutilisés par tous les sites.
  
  > On voudrait avoir des briques fonctionnelles isolées.
  > On a fait ça dans le _rush_ et on n'en a peut-être pas assez parlé.
  
  [horizontal]
  Opportunités::
    * Étendre les sujets couverts par cette équipe ;
    * L'intégrer à l'équipe UX pour en faire une équipe transverse et reproduire le succès du SDK API côté front-end.
  
  
  ### Observations équipe UX
  
  Beaucoup de sujets ont été évoqués, dont celui d'une charte graphique (voire d'un _styleguide_) en cours de réalisation.
  Ce sujet a aussi été évoqué par au moins deux équipes chaînes.
  
  Les designers sont embarqué·e·s dans les équipes chaînes en fonction des demandes et de la charge de travail.
  Une personne peut travailler en alternance pour l'équipe _Culture_ et _France Bleu_, par exemple.
  
  [horizontal]
  Succès::
    * Les compétences UX et UI deviennent reconnues ;
    * L'émergence d'un besoin de _styleguide_ fait consensus.
  
  Frictions::
    * Il n'y a pas un consensus évident quant à la responsabilité de produire du code ;
    * Il n'y a pas non plus consensus sur la diffusion du guide et du suivi de son implémentation.
  
  Opportunités::
    * Un rapprochement avec les équipes chaînes pourrait être utile afin de mieux coordonner les efforts ;
    * Partager les outils de documentation pour bénéficier d'une documentation multi-disciplinaire ;
    * S'orienter vers une utilisation de link::https://www.sketchapp.com/[Sketch] combinée à link::https://www.goabstract.com[Abstract] (versioning avec Git), link::https://www.invisionapp.com/craft[Craft] (prototypage et consommation des API) et link::http://airbnb.io/react-sketchapp/[React Sketch.app] (rendu de composants React) pour créer des composants communs aux sites web et app mobiles.
  
  ### Observations équipe mobile
  
  ### Observations équipe marketing
  
  Nous entamons une discussion après avoir lu le mot *documentation* sur un post-it affiché sur un tableau blanc.
  
  > Les gens de la technique, ils ne viennent pas nous voir.
  
  > J'ai plein de données _analytics_ que j'ai du mal à récupérer.
  
  [horizontal]
  Frictions::
    * L'outil de documentation _de facto_ est l'email ;
    * On a ressenti une certaine souffrance liée à l'isolation technique et à une charge de travail continue ;
    * Beaucoup d'actions manuelles sont nécessaires pour collecter les informations nécessaire
  
  Opportunités::
    * Former Deborah à être _Product Owner_ ;
    * Doter l'équipe d'un·e _Product Owner_ ;
    * Partager les outils de documentation pour bénéficier d'une documentation multi-disciplinaire ;
    * Venir livrer des rapports succincts aux différentes foires pour informer des impacts des équipes ;
    * Organiser une foire pour susciter l'intérêt des autres équipes (techniques et produits) ;
    * Designer une _API Business_ pour refermer la boucle de _feedback_.
  
  ### Observations projet _Open Data_
  
  