CR_2020_05_06
- Mathias André
- Antoine Dreyer (DSI)
- Gilles Fidani
- Lino Galiana
- Gaëlle Génin
- Pierre Lamarche
- Claire Legroux (DSI, DPII, animatrice du réseau LS2)
- Romain Lesur
- Olivier Meslin
- Benoit Rouppert (DSI, chef du DPII)
- quelques grosses fiches restent à réaliser (
tidyverse, cartographie,rmarkdown); - début de création d'un package pour télécharger des données d'http://insee.fr/, qui contient également les données utilisées comme exemple dans la documentation.
- la partie 1 reste à faire (comment travailler avec
Rà l'Insee), plus tard après le déploiement d'AUS V3.
📆 Les objectifs que le groupe s'est fixé
- fin de la rédaction de la partie 3 d'ici début juin (hors fiche carto);
- fin juin pour la partie 1;
- relectures et tests de la doc en juin/juillet;
- diffusion de la doc en septembre;
Une interrogation sur le blocage de la rédaction de la partie 1 dû au fait qu'AUS V3 n'est pas encore en production (il le sera fin juin, des tests seront lancés avant). Réponses:
- Normalement la rédaction de la partie 1 ne sera pas trop longue, car des documents existants peuvent être réutilisés.
- Certains détails techniques peuvent modifier les préconisations (clé ssh, Rstudio, ...). De plus, il y a un réel besoin d'être connecté à l'environnement, pour faire des captures d'écran, simuler l'expérience utilisateur (UX).
La valeur ajoutée des remarques et des conseils est soulignée. Il faudrait peut-être aller plus loin, et identifier notamment les usages des agents. Une question sur la position du guide des bonnes pratiques (en fin de doc) est posée. Il sera relativement aisé de réorganiser le document après coup. La nécessité de distinguer petites et grosses fiches semble également faire consensus.
Il faudrait également veiller à faire la distinction entre les bonnes pratiques d'ordre général, et les bonnes pratiques sur des opérations particulières, comme les jointures par exemple.
Il faut signaler dans le document qu'utilitR est réalisé (notamment) par des membres de LS2, qu'il s'agit d'un travail collaboratif, qui a vocation à évoluer. Il faut veiller à faciliter la mise en relation des membres du réseau avec tous les agents désireux de prendre contact avec eux. L'introduction de la documentation pourra aborder ces éléments.
La question de la diffusion papier est posée. Le document pdf laisse l'opportunité aux agents d'imprimer, selon leurs besoins et leur mode de travail. La possibilité d'une diffusion plus organisée sous forme de brochure reliée est mentionnée, sans décision à ce stade.
La nécessité d'une url stable - par exemple sur un domaine en insee.fr, et mis en open source sur un compte gitlab par exemple, est soulignée et largement acceptée.
Une discussion s'est engagée sur la reprise d'éléments soumis à licence (formation de Julien Barnier et supports de formation du MTES). Il serait peut être intéressant de voir plus loin que la licence : si le projet est utile pour toute la communauté (hors Insee), il serait judicieux de le diffuser largement, de le rendre public (au moins partiellement, certaines parties n'ayant pas vocation à sortir de l'Insee).
La question de l'infrastructure pour le déploiement de la documentation est également posée : sur le gitlab "de prod" qui commence à être déployé ? celui qui a vocation a reprendre les éléments de gforge ? Il existe plusieurs supports potentiels de diffusion. Il faut pour cela se renseigner sur les procédures d'alimentation du gitlab / github Insee. Pour gitlab, une demande est à adresser à Mylène Chaleix, cc Juliette Fourcot, Franck Cotton et Denis Marchal
La démarche atypique (bottom up, organisation horizontale) est mise en avant. Celle ci repose notamment sur une procédure de revue par les pairs.
Des questions se posent sur la maintenance et la pérennisation du projet. Il serait possiblement souhaitable que cette initiative donne lieu à une appropriation par la hiérarchie.
La généralisation de la démarche devrait être reportée à plus tard. Il faut dans un premier temps faire vivre le projet. Il pourra servir d'exemple par la suite.
Concernant l'appel à de nouvelles candidatures, on notera que la relecture est déjà une forme de contribution, tout comme l'expression d'un avis sur une issue.
Point d'attention : ne pas se fixer trop d'objectifs, ou d'objectifs trop ambitieux.
Il est également important de réfléchir à l'articulation entre utilitR et USSR. Il ne faudrait pas que le projet génère des conflits.
La démarche a rencontré un franc succès, les participants ont (unanimement?) apprécié cette façon de collaborer, et souhaitent l'encourager à l'avenir (pas seulement pour R, mais pour d'autres projets).
On peut avoir deux visions du projet utilitR: il s'agit à la fois d'un produit de documentation pour les agents de l'Insee, mais aussi d'une sorte de preuve de concept, qui montre qu'un projet lancé "d'en bas" par des agents peut avancer efficacement et être une réussite.
Il faudrait mettre en avant le principe de cette démarche, et trouver des moyens de promouvoir ce type d'initiative (voire de les encourager). Ce serait dommage de ne pas capitaliser dessus.
Le niveau d'exigence / d'approbation que s'impose le groupe est relativement élevé. Il pourrait être intéressant de réfléchir au principe de démarche inner source (mettre en oeuvre les pratiques de l'open source au sein d'une organisation). Ceci suppose une structuration qui reste à penser et à mettre en place pour les projets qui suivent ce mode de dvpt. Des difficultés de coordination / urbanisation des projets qui se recouvrent parfois sont à anticiper.
La question de l'organisation de la maîtrise d'ouvrage et de la gouvernance du projet est évidemment centrale pour la poursuite à long terme de celui-ci. Un équilibre sera nécessaire entre l'institutionnalisation du projet et une démarche collaborative dont tout le monde s'accorde à saluer l'efficacité. L'utilisation de termes déjà réconnus à l'Insee comme "maîtrise d'ouvrage", et plus généralement l'inscription dans des structures et de logiques préexsitantes permettra de renforcer l'intelligibilité du projet.
La DSI en général, et le DPII en particulier sont déjà maîtrise d'ouvrage d'outils transversaux, à la gouvernance desquels peuvent participer les directions métiers de l'Insee. Cette logique est proche de celle d'une communauté open source, où tout le monde est propriétaire de ce qui est produit. Comme UtilitR vient aider à l'utilisation d'outils informatiques dont le DPII assure la maîtrise d'ouvrage, il est légitime et efficace que le DPII continue d'assurer la maîtrise d'ouvrage d'UtilitR. Il reste à préciser comment faire participer les directions métiers de l'Insee, c'est à dire comment constituer un pilotage horizontal de ce projet.
En premier lieu ce projet est trop petit pour justifier la création d'une structure exprès ; mieux vaut le rattacher à une structure existante. Le réseau LS2 paraît le meilleur ratachement possible : il est par nature suffisamment souple pour s'adapter aux évolutions du projet, et il permet de faire travailler officiellement des agants de l'Insee quel que soit leur lieu d'affectation. Rappelons que le réseau LS2 permet de sortir du cadre de travail de son unité, et que ses membres y participent à hauteur 5 à 10 % de leur temps de travail, par contrat entre eux et leur supérieur hiérarchique ; cette contractualisation lève une grande partie des ambiguïtés et des difficultés de ce type de collaboration, c'est-à-dire fondamentalement l'arbitrage entre travail de l'unité de rattachement, et travail pour le réseau.
Il reste donc à créer un véritable comité de pilotage du réseau LS2, qui réunira une à deux fois par ans des représentants du réseau et des directions métiers de l'Insee ; ces réunions pourront se faire en parallèle des séminaires annuels déjà existants. Ce comité n'aura bien sûr pas vocation à régler les moindres détails du fonctionnement du projet ; celui-ci devra donc poursuivre l'écriture de ses propres règles de gouvernance internes.
Les conséquences pour le réseau LS2 seront bénéfiques, car le réseau vit au travers de ses membres et de leur dynamique : il y aura une plus grande reconnaissance du réseau grâce à utilitR, et réciproquement. Et les besoins de pilotage formel du réseau dépassent largement UtilitR.
Le réseau LS2 doit faire la publicité d'utilitR et faire connaitre le projet pour en assurer l'appropriation par les agents.
La question de l'endossement de ce projet par l'Insee est posée, afin de le rendre plus officiel. Si le réseau LS2 est endossé, ça le rend officiel. Si on veut aller + loin, il faut inclure la formation (en faire éventuellement un complément des supports de formation). Dans ce cas, utilitR deviendrait naturellement une référence. La documentation pourrait être fournie par l'Insee avec tampon LS. En discuter avec la formation permettrait déjà d'engager des échanges. Il est fait mention d'une initiative un peu similaire à l'université de Rennes. On peut également imaginer la présentation du projet lors de séminaires, en faire un sujet de présentation.
Se pose également la question de la reconnaissance du réseau LS2. On pourrait envisager de créer un logo LS2 qui mentionnerait l'institut.
Une documentation avec le logo Insee, datée et millésimée est de nature à rassurer les agents. Il serait également utile de se renseigner pour une éventuelle diffusion sur https://www.epsilon.insee.fr (site documentaire/archivage). La publication sous forme de document de travail (document à lucarne) peut également être envisagée.
Une activité de convivialité réunissant les membres du projet est envisagée, afin de saluer les efforts individuels et collectifs, et créer du lien entre les participants. Les modalités restent à définir.
La prochaine réunion aura lieu le 10 juin 2020.
