Présenté par Fabrice Bloch (INSEE) et Jean-Séverin Lair (INSEE) à Agile en Seine le 20 septembre 2023 En duo avec le DSI de l’INSEE, l’idée est de présenter nos illusions et nos erreurs dans le cadre de la transformation devops de l’Insee. Nous essaierons d’expliciter les hypothèses que nous avions, et qui étaient fausses, et ce que nous avons appris.

1. 19 & 20 septembre 2023 - Paris, Niort
On s’est bien plantés
…mais nous avons appris
Jean-Séverin Lair - Fabrice Bloch

2. PLATINUM SPONSOR
GOLD SPONSOR
SILVER SPONSOR
PARTENAIRE

3. Posez vos
questions !

4. Vos orateurs
Jean-Séverin LAIR
DSI INSEE
Fabrice BLOCH
Chef du centre agile INSEE
@AgilitatrPublic

5. Notre intention

6. Le plan
I. Le contexte
II. Nos crédos
III. Nos 9 premiers
plantages
Ils se disent agiles et ils font UN PLAN ?

7. Le contexte

8. L’Insee, une direction du ministère des finances
5000 agents
quand on rentre à l’INSEE c’est pour 42 ans de carrière
90% d’Insee (avec écoles propres)
5% de contractuels
5% de fonctionnaires non-Insee

9. Une DSI agile depuis 15 ans et en mutation DevOps
● Agilité
○ Premières discussions autour de l’agilité en 2007
○ Premiers tests en 2009-2010
○ Généralisation vers 2015
○ Exclusivité depuis 2020
● DevOps
○ Premières discussions en 2019
○ Lancement d’un projet de transformation mi-2021
○ Prise de la dynamique début 2023

10. Un bureau des méthodes devenu Centre Agile
● Bureau des méthodes datant des
années 80-90 en lien avec la mise en
place des démarches projets
● Double compétence dès 2010
(waterfall + agilité)
● Centre agile depuis 2021

11. Nos crédos

12. Manifeste über alles
● Les individus et leurs interactions plus que les processus et
les outils
● Des logiciels opérationnels plus qu’une documentation
exhaustive
● La collaboration avec les clients plus que la négociation
contractuelle
● L’adaptation au changement plus que le suivi d’un plan
… avec une petite faiblesse pour la 4ème!

13. Non au prêt-à-penser

14. Ceux qui savent font et ensemble
Dans un domaine à forte technicité et rapidement évolutif
ceux qui font doivent savoir. Le cercle vertueux n’est pas
induit par le contrôle mais par la confiance et l’amélioration
… il faut valoriser la compétence technique et favoriser
l’expression du potentiel de chacun par le collectif

15. Transformation pérenne

16. Nos 9 premiers plantages

17. 1- Le consultant-héros
2- Avaler une seule grosse bouchée à la fois
3- Cajoler le manager intermédiaire ?
4- L’illusion de l’agilité mature
5- Aux bons ouvriers les bons outils
6-Mode produit et bureaucratie
7- Les projets témoins
8- Cure de désintoxication des specs
9- … et une vision pour les gouverner tous !

18. #1 le consultant
héros
Oui… erreur de débutant!

19. Nos croyances

20. Nos actions

21. Les faits
● L’incompréhension des modes de fonctionnement existants et des ateliers vécus comme “pliés
d’avance”, plaquant un modèle
● Le déficit d’expérience (voire de compétences sur certains aspects) de la part du prestataire
● La perte de contrôle de la prestation faute de capacité d’investissement interne
● Une mobilisation minimale des équipes
● Un résultat de prestation qui appelle une autre prestation… de mise en place (il faut bien que les
sociétés de conseil travaillent…)

22. Nos apprentissages
Un consultant n’est qu’un amplificateur d’action il ne peut pas faire à la place
la connaissance du terrain de départ est importante, ⇒ investir une équipe interne pluri-disciplinaire et
opérationnelle (GT DevOps)
il faut que la haute hiérarchie s’implique profondément y/c dans son ADN (consultations, formation
SRE…)

23. 1- Le consultant-héros
2- Avaler une seule grosse bouchée à la fois
3- Cajoler le manager intermédiaire ?
4- L’illusion de l’agilité mature
5- Aux bons ouvriers les bons outils
6-Mode produit et bureaucratie
7- Les projets témoins
8- Cure de désintoxication des specs
9- … et une vision pour les gouverner tous !

24. #2 avaler une seule
grosse bouchée à
la fois

25. Nos croyances
Contexte
● Déménagement par reconstruction de l’ensemble de notre centre de prod avec mise en place sur
deux nouveaux sites distincts (environ 9 000 VM)
● Evolution DevOps rendu nécessaire par hiatus entre devs Agile et ops Itil
… on va faire les deux en même temps en cherchant les quickwin du DevOps ce qui nous donnera un peu
de mou pour ne pas bloquer totalement l’évolution de la prod pendant le déménagement

26. Nos actions
● Lancer la mise en oeuvre du plan DevOps défini avec le prestataire en parallèle du déménagement

27. Les faits
● Le déménagement était une contrainte opérationnelle, quotidienne et incontournable forte, qui
réduisait fortement la disponibilité des Ops
● Les Quickwins n’ont jamais pu être mis en place
● La complexité de la mise en place de la transformation a été mise en évidence

28. Notre apprentissage
… Il faut que le commanditaire ose reconnaître les erreurs de prestataire
… Il faut toujours oser s’adapter et sortir du chemin tracé en observant les signaux forts et faibles
Toute crise peut cacher des opportunités intéressantes
● Recherche de temps des Ops qui allait dans le sens de la transformation attendue (les
“devs-intégrateurs”)
● Si les Ops n’ont pas le temps que faire qui va dans le même sens… du Craft avec les devs

29. 1- Le consultant-héros
2- Avaler une seule grosse bouchée à la fois
3- Cajoler le manager intermédiaire ?
4- L’illusion de l’agilité mature
5- Aux bons ouvriers les bons outils
6-Mode produit et bureaucratie
7- Les projets témoins
8- Cure de désintoxication des specs
9- … et une vision pour les gouverner tous !

30. #3 cajoler le
manager
intermédiaire ?

31. Nos croyances

32. Nos actions

33. Les faits
● Certains managers ont mal vécu la valorisation des opérationnels et y ont vu la dévalorisation de
leur rôle

34. Notre apprentissage
… il faut traiter spécifiquement et explicitement le positionnement des managers dans une
transformation des modes de travail
… une transfo, même apparemment tech, impacte le rôle du manager
Reste une question ouverte “comment accompagner des managers “bureaucratiques” dans le nouveau
cadre?”

35. 1- Le consultant-héros
2- Avaler une seule grosse bouchée à la fois
3- Cajoler le manager intermédiaire ?
4- L’illusion de l’agilité mature
5- Aux bons ouvriers les bons outils
6-Mode produit et bureaucratie
7- Les projets témoins
8- Cure de désintoxication des specs
9- … et une vision pour les gouverner tous !

36. #4 illusion de
l’agilité mature

37. Nos croyances
Contexte:
● 15 ans d’agilité
… on a une sérieuse expérience et les bases sont acquises. On a un socle

38. Nos actions
● On a expliqué à certains qui, arrivant de l’extérieur (dont le DSI) lançaient des alertes sur le sujet,
que tout allait bien
● On est passés au Lvl 2 (+ Design UX, + DevOps…) en considérant les bases acquises

39. Les faits
● La pratique apparente cache de grandes disparités
● La découverte de manques potentiels a déclenché une réaction de protection par déni des équipes
et de leur hiérarchie

40. Notre apprentissage
● En agilité comme dans d’autres domaines d’expertise, rien n’est acquis : ne pas lâcher
● L’entropie s’installe et le niveau baisse (mais pas l’illusion !) en renforçant de mauvais plis
… il faut régulièrement interroger les pratiques au delà des équipes à un niveau plus transverse (la rétro c’est
bien mais cela ne suffit pas!)
… il est utile de faire des piqûres de rappel (reboot agile) avec des appuis externes “pure-players” pour s’assurer
d’un socle montant
● formation (notamment PO et SM)
● consulting
● coaching

41. Et du coup

42. 1- Le consultant-héros
2- Avaler une seule grosse bouchée à la fois
3- Cajoler le manager intermédiaire ?
4- L’illusion de l’agilité mature
5- Aux bons ouvriers les bons outils
6-Mode produit et bureaucratie
7- Les projets témoins
8- Cure de désintoxication des specs
9- … et une vision pour les gouverner tous !

43. #5 aux bons
ouvriers les bons
outils

44. Nos croyances

45. Nos actions

46. Les faits
● Une peine à convaincre
● Une peur du flicage
● Une résistance des devs

47. Notre apprentissage
… la 1ère valeur est mal comprise : il faut aussi des process et des outils
… l’agilité sert encore pour certain comme alibi de faiblesse du pilotage (cf point précédent)
… il faut réaffirmer que l’agilité n’empêche pas le pilotage, au contraire ! L’agilité est LA solution pour
répondre aux contraintes de budget et de délai. C’est un raté du passé d’avoir laissé croire le contraire.

48. 1- Le consultant-héros
2- Avaler une seule grosse bouchée à la fois
3- Cajoler le manager intermédiaire ?
4- L’illusion de l’agilité mature
5- Aux bons ouvriers les bons outils
6-Mode produit et bureaucratie
7- Les projets témoins
8- Cure de désintoxication des specs
9- … et une vision pour les gouverner tous !

49. #6 mode produit et
bureaucratie

50. Nos croyances
… le mode produit est l’approche utile aujourd’hui afin de faire évoluer notre organisation, et avoir des SI
répondant au mieux aux besoins de l’organisation

51. Nos actions

52. Les faits
● La difficulté de faire entrer le rôle du PO dans une grille administrative
● Un arbitrage complexe entre responsabilité et disponibilité
● Des postures très disparates et toujours en forte tension

53. Notre apprentissage
L’approche produit est globalement contradictoire avec le fonctionnement
bureaucratique des grandes organisations.
… c’est possible si le management “fait comme si”
… il faut mettre en place des contrats moraux avec les PO
… il faut mettre en place des formations PO dans le contexte managérial spécifique
de la structure

54. Des bootcamps et des dojos
#DialogicBoys

55. 1- Le consultant-héros
2- Avaler une seule grosse bouchée à la fois
3- Cajoler le manager intermédiaire ?
4- L’illusion de l’agilité mature
5- Aux bons ouvriers les bons outils
6-Mode produit et bureaucratie
7- Les projets témoins
8- Cure de désintoxication des specs
9- … et une vision pour les gouverner tous !

56. #7 Les projets
témoins

57. Nos croyances
…il faut des projets témoins pour tester avant de généraliser

58. Nos actions

59. Les faits
On a arrêté.

60. Notre apprentissage
Plutôt une interrogation à ce stade … les projets témoins sont-ils vraiment une bonne idée ?
.. nous avons finalement décidé de passer en amélioration pas à pas pour faire monter tout le monde en
même temps.

61. 1- Le consultant-héros
2- Avaler une seule grosse bouchée à la fois
3- Cajoler le manager intermédiaire ?
4- L’illusion de l’agilité mature
5- Aux bons ouvriers les bons outils
6-Mode produit et bureaucratie
7- Les projets témoins
8- Cure de désintoxication des specs
9- … et une vision pour les gouverner tous !

62. #8 Cure de
désintox des specs

63. Nos croyances
… le concept de specs préalables relues et certifiées avant transmission à l’IT est dépassé et chronophage
C’est basé sur deux fausses croyances, facilement objectivables :
● il est possible de tout expliquer avant de coder puisque le métier sait ce qu’il veut et que
l’informatique saura le développer
● les specs, c’est le legacy : la doc qui perdure

64. Nos actions
● Des instructions claires ont été données : “pas de specs écrites préalables, écrivez les users stories
collaborativement”
● Ce sujet a été porté plusieurs fois en intervention large par le DSI

65. Les faits
… Rien ne change !
● On ne nous croit pas (“pas pareil chez nous”)
● C’est encore fréquemment un blocage qui remonte (“on peut rien faire, le métier a pas fait les
specs”)

67. Notre apprentissage
… on a sous-estimé la force et l’ancienneté de cette croyance… une vraie “vache sacrée”
… c’est à l’INSEE une limite majeure de l’adoption de l’agilité
HELP: si vous avez des tips pour tuer la “vache sacrée” SPECS on est preneurs…

68. 1- Le consultant-héros
2- Avaler une seule grosse bouchée à la fois
3- Cajoler le manager intermédiaire ?
4- L’illusion de l’agilité mature
5- Aux bons ouvriers les bons outils
6-Mode produit et bureaucratie
7- Les projets témoins
8- Cure de désintoxication des specs
9- … et une vision pour les gouverner tous !

69. #9 et une vision
pour les gouverner
tous

70. Nos croyances
…il est possible d’obtenir des équipes une solution émergente sous réserve d’être clair sur la vision
… il faut le moins d’écrit possible pour éviter le syndrôme du “chef a dit” et laisser ouverte la création
d’une solution intelligente

71. Nos actions
● Présenter oralement fréquemment une vision stratégique, basée sur les enjeux et les opportunités
● Créer des espaces de travail collectif et de consultation

72. Les faits
● Incompréhension de l’absence de prescription explicite de la hiérarchie, et notamment d’écrit
● Attente non seulement d’orientations mais aussi du “comment”
● “Ce n’est pas à moi de définir comment je vais travailler avec les autres”

73. Notre apprentissage
… il faut terriblement se méfier de l’ impuissance acquise
… il est plus difficile de créer sans base d’adhésion ou d’opposition : la création a besoin de contraintes
… le plus efficace est d’agir en tenaille en construisant la cible par le haut et par le bas de manière
itérative et incrémentale
La direction a posé une vision par écrit mais en veillant à avoir 3 modalités: détaillée/rédigée en 30 pages,
en liste de points en 2 pages et en story-telling en 4 pages (ce dernier mode a été très apprécié en
donnant du sens concret)

74. 1- Le consultant-héros
2- Avaler une seule grosse bouchée à la fois
3- Cajoler le manager intermédiaire ?
4- L’illusion de l’agilité mature
5- Aux bons ouvriers les bons outils
6-Mode produit et bureaucratie
7- Les projets témoins
8- Cure de désintoxication des specs
9- … et une vision pour les gouverner tous !

75. Nos autres
apprentissages

76. D’autres apprentissages (pour la V2 de la conf’)
● l’acculturation agile des ops diffère de celle des devs
● l’impuissance acquise est un fléau à tous les niveaux d’une organisation bureaucratique
● la loi de Hofstadter frappe même en Agile (« Il faut toujours plus de temps que prévu, même en
tenant compte de la loi de Hofstadter. »)
● …

77. Conclusion

78. En synthèse…
Se transformer c’est se raconter ensemble une histoire commune : les individus et les
interactions… (valeur #1)
Planifier est plus important que le plan (valeur #4)
Aller chercher les valeurs et les croyances comme les process et les outils
Humilité, expérimentation et feedbacks !

79. L’effet Dunning-Kruger
Dans notre avancée Agile et dans notre capacité
de transfo DevOps, on a appris, on a acquis à prix
fort le recul nécessaire
… se regarder sans indulgence fait mal mais le
premier savoir est le savoir de son ignorance (ἕν
οἶδα ὅτι οὐδὲν οἶδα… Platon)
… on est sur le chemin de la remontée alliant
compétence et confiance!

80. Et vous ?

81. On s’est bien plantés
…mais nous avons appris
Jean-Séverin Lair, DSI
Fabrice Bloch, chef du centre agile Contactez-nous
sur LinkedIn !
Questions ?

82. Merci
https:/
/roti.express/r/ae
s2023-58