* 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.
:calendar: 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).
- 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 LS<sup>2</sup>, 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.
## Public cible
La nécessité d'une url stable, sur un compte gitlab `insee.fr` 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
## Démarche du projet
La démarche atypique (*bottom up*) 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 mise à jour du projet. Il serait également intéressant que cette initiative donne lieu à une appropriation par la hiérarchie.
La question de l'organisation de la gouvernance et la supervision du projet est importante.
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).
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.
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.
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*.
Il faudrait mettre en avant le principe de cette démarche, et trouver des moyens de promouvoir ce type d'initiative (voir de les encourager). Ce serait dommage de ne pas capitaliser dessus.
Point d'attention : ne pas se fixer trop d'objectifs, ou d'objectifs trop ambitieux.
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.
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.
Un équilibre est à trouver : il faut à la fois ancrer la démarche pour la rendre visible, "l'institutionnaliser", sans pour autant casser la démarche collaborative.
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).
*off the record* : il ne faudrait pas que le COPS s'approprie le sujet. Le faire porter par le réseau LS<sup>2</sup> semble plus pertinent (profiter de la liberté du réseau). Le réseau LS<sup>2</sup> 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 LS<sup>2</sup> 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.
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.
Se pose également la question de la reconnaissance du réseau LS<sup>2</sup>.
LS<sup>2</sup> est un réseau **de l'Insee**. On pourrait envisager de créer un logo LS<sup>2</sup> qui mentionnerait l'institut. Cela permettrait déjà d'identifier des contacts. LS<sup>2</sup>, c'est l'animation d'un réseau avec son coté informel. LS<sup>2</sup> permet de sortir du cadre de travail de son unité. Le réseau ne peut vivre qu'au travers de ses membres et de leur dynamique. Il pourrait y avoir une plus grande reconnaissance du réseau grâce à `utilitR`, et réciproquement.
Il faudrait mettre en avant le principe de cette démarche, et trouver des moyens de promouvoir ce type d'initiative (voir de les encourager). Ce serait dommage de ne pas capitaliser dessus.
Pour autant, il ne faut pas oublier l'origine du projet, en auto saisine. Il y a un enjeu de définir un objectif et de le formaliser. LS<sup>2</sup> pourrait être MOA d'utilitR. Il y a une certaine importance à "l'inscrire dans le marbre" et à communiquer dessus. Les directions de l'Insee verraient ainsi qu'avoir un pied dans le réseau permet d'avoir un impact sur certains sujets (pas seulement R, mais d'autres à venir).
Un comité de pilotage **horizontal** semble nécessaire pour la bonne gestion du projet. Attention toutefois au vocable MOA/MOE, généralement associé à une démarche *waterfall* (descendante), en orthogonalité avec la démarche du projet utilitR. L'usage du vocable peut cependant constituer une forme de cheval de Troie, et rendre les choses intelligibles. Il faut passer d'une logique où une MOA est seule propriétaire, à un projet qui vise la création d'un "bien commun". La difficulté du glissement sémantique est signalée.
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.
On pourrait presque penser cela comme une assemblée de copropriétaire (en faisant abstraction de la pénibilité de ce type de réunion). Dans une communauté open source, tout le monde est propriétaire de ce qui est produit. Il faut pour cela être au clair sur nos objectifs. Nous avons contractualisé que nous donnons 5 à 10 % de notre temps de travail pour LS<sup>2</sup>. Il est important de le signaler, car cela permet de lever une grande partie des ambiguïtés et des difficultés de ce type de collaboration (arbitrage entre travail de l'unité de rattachement, et travail pour le réseau). LS<sup>2</sup> est la pour aider les initiatives à vivre, mais il faut que le projet écrive ses propres règles de gouvernance (ce qui a déja été initié).
Un référence au projet `Opposum` est faite concernant le mode de gouvernance transversale (à compléter, je n'ai pas bien compris)
## Gouvernance
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 institutionnalisation du projet et 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 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.
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 assurent 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.
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*.
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 LS<sup>2</sup> paraît le meilleur ratachement possible :elle est par nature suffisamment souple pour s'adapter aux évolutions du projet, et elle permet de faire travailler officiellement des agants de l'Insee quel que soit leur lieu d'affectation. Pour rappel,LS<sup>2</sup> permet de sortir du cadre de travail de son unité, et
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.
Point d'attention : ne pas se fixer trop d'objectifs, ou d'objectifs trop ambitieux.
Il reste donc à créer un véritable comité de pilotage du réseau LS<sup>2</sup>, 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.
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.
Les conséquences pour le réseau LS<sup>2</sup> 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.
## Appropriation par les agents
Le réseau LS<sup>2</sup> 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 LS<sup>2</sup> 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 LS<sup>2</sup>. On pourrait envisager de créer un logo LS<sup>2</sup> 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.
...
...
@@ -98,6 +100,4 @@ Une documentation avec le logo Insee, datée et millésimée est de nature à ra
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.
## Réunion suivante
La date du 10 juin est annoncée, et devrait faire l'objet d'une confirmation dans les jours à venir.
