- Speaker #0
Typiquement, vous dites, bon, OK, il y a les valeurs, mais il y a plein d'autres choses, etc. Moi, j'inverserais la proposition quand même. Il y a plein de choses, mais il faut toujours revenir aux valeurs. Et pour moi, c'est absolument essentiel, les quatre valeurs de l'agilité, c'est vraiment la base et c'est ce qu'il ne faut pas perdre de vue. Et c'est ce qu'un certain nombre de frameworks, à mon avis, perdent de vue. Et c'est fort dommage.
- Speaker #1
Bonjour à tous, moi, c'est Bertrand Ruiz, le CEO d'Ersas, l'outil de gouvernance projet qui révolutionne la façon dont les directions peuvent prendre des décisions éclairées. Et je vous souhaite la bienvenue sur le podcast CIR Evolution. Dans cette saison dédiée à l'agilité dans l'entreprise en 2023, en partenariat avec Valiantis, qui est partenaire Atlassian spécialisé Agile Scale, nous allons creuser à fond cette thématique. Une entreprise qui est agile, ça veut dire quoi ? Quel est le niveau d'investissement nécessaire du DG ? Comment mettre en place une démarche agile dans une ETI, dans une collectivité ? Comment gérer les budgets quand on fait de l'agile ? Quel est le principal bénéfice à ce type de démarche ? Dans un contexte de crise à répétition, il est important de questionner notre capacité à nous organiser. C'est cela que nous aurons voulu faire avec cette saison. Bonne écoute à tous !
- Speaker #2
Bonjour à tous, je suis ravi aujourd'hui d'être avec Jean-Séverin Lerre qui est le DSI de l'INSEE. Bonjour Jean-Séverin.
- Speaker #0
Bonjour.
- Speaker #2
On a pu échanger un petit peu il y a quelques temps, et avant de rentrer dans le vif du sujet qui est l'agilité dans l'organisation, pas forcément publique, mais dans l'organisation, bien sûr, il y a des spécificités, on y viendra. Est-ce que tu peux présenter ce que fait l'INSEE, même si les gens connaissent le nom, c'est toujours important de le préciser.
- Speaker #0
L'INSEE, oui, est assez connue parce qu'elle est régulièrement citée, ne serait-ce que dans les médias. En fait, c'est l'Institut de la statistique et des études économiques et son objet, c'est d'informer et d'aider à la prise de décision les pouvoirs publics, mais aussi les entreprises, la société en général, à travers justement les indicateurs, les statistiques, les référentiels qu'elle peut créer et gérer.
- Speaker #2
Par curiosité, ces statistiques-là, elles sont tout le temps, par exemple, dans l'économie, etc., ou est-ce qu'elles sont aussi dans… Par exemple, on voit beaucoup l'ADEME qui fait beaucoup d'aides à la décision sur des politiques publiques énergétiques. C'est quoi le périmètre d'ADEME ?
- Speaker #0
Le périmètre de l'INSEE est à la fois sur tout ce qui est économique, société, entreprise, etc., mais aussi démographique, par exemple, les statistiques sur les naissances, les décès, la population française, sa démographie, etc. Le recensement aussi de toute la population, c'est quelque chose de très important, une étape très forte et très lourde pour l'INSEE chaque année. Donc c'est très varié. Et l'INSEE est à la tête aussi de ce qu'on appelle le service statistique public, qui est en fait l'ensemble des acteurs qui font des stats dans tous les ministères, dans différents organismes. Et donc globalement, c'est cet ensemble-là qui apporte tous les indicateurs qui sont utiles à la compréhension et à la prise de décision. L'INSEE a une vision un peu plus transverse et globale, et après il y a d'autres acteurs qui sont spécialisés, quand vous citez l'ADEME par exemple, mais on a aussi dans chaque ministère un service qui est spécialisé sur son domaine.
- Speaker #2
et est-ce qu'il s'est agi un peu comme une DSI groupe de bonne pratique auprès de les équipes à l'intérieur des autres ministères ? Est-ce qu'il y a un partage de connaissances, d'outils, de façons de faire ou est-ce qu'ils sont assez indépendants ?
- Speaker #0
Alors DSI groupe non parce que chaque ministère est très indépendant et tient à son indépendance. Par contre, on a vraiment un rôle je pense sur tout ce qui est innovation dans la gestion de... je dirais de la data science, des outils qui peuvent exister. Et d'ailleurs, l'INSEE a une souche libre qui s'appelle Onyxia pour déployer facilement des environnements de data science qu'on déploie et qui est réutilisé à l'extérieur.
- Speaker #2
Et du coup, je me souviens juste pour un petit peu qui vous êtes et votre parcours, comme ça on va pouvoir après évaluer le sujet.
- Speaker #0
Alors, moi, je suis un fonctionnaire technophile avec un goût pour l'innovation. Ici, les trois sont compatibles. Je suis dans le numérique depuis 30 ans et puis j'ai fait des postes dans toutes sortes d'entités. Mes trois derniers postes, c'était DSI du ministère de la Culture, directeur d'un programme agile et maintenant DSI de l'INSEE.
- Speaker #2
Du coup, vous parlez de programme agile. À l'INSEE, ça fait combien de temps que vous êtes là ?
- Speaker #0
Ça fait trois ans maintenant.
- Speaker #2
Donc, trois ans, petit départ à rapport des temps de main et donc, du coup, volonté de mise en place d'une culture agile. Est-ce qu'on peut en revenir un petit peu sur… Il y a trois ans, quand vous arrivez à l'INSEE, qu'est-ce que vous découvrez ? Quel est votre constat et quelle est votre volonté ?
- Speaker #0
Alors, quand j'arrive à l'INSEE, je découvre déjà une administration qui a commencé à penser l'agile depuis 2009 environ. Donc, ce n'était pas si tard que ça par rapport à d'autres. Et en tout cas, pour les administrations, c'était très tôt. et qui s'est lancé avec un premier projet en 2010. Et bon, ça, ça fait toujours rire à l'intérieur de la maison, avec un projet qui était sur quelque chose de critique. parfois, on joue de manière risquée. Et ça s'est relativement bien passé, mais ce n'est pas étonnant parce que de toute façon, c'était les pionniers qui avaient envie, qui voulaient démontrer que ça allait marcher et tout. Donc, au bout du compte, ce n'était pas une mauvaise idée de le faire avec ces gens-là. Depuis, je dirais jusqu'en 2020, la culture s'est généralisée sur l'agilité et maintenant, tous les projets sont lancés en agile. Donc voilà, ça, c'est ce que j'ai trouvé.
- Speaker #2
Si je peux me permettre vos métiers à l'intérieur de l'INSEE, c'est des statistiques.
- Speaker #0
Exactement. Alors, on a une caractéristique un peu spéciale de tout ce que j'ai pu connaître dans mes autres postes, c'est que vous n'avez pas besoin d'expliquer à un statisticien qu'il a besoin de l'informatique pour travailler.
- Speaker #2
Oui, c'est des métiers qui sont déjà super à l'écoute des solutions techniques.
- Speaker #0
Alors, non seulement super à l'écoute, mais je dirais déjà avec une culture numérique de base qui n'est pas négligeable du tout. Et en fait... Ceux qui s'occupent d'informatique à l'INSEE sont pour la plupart avec les mêmes origines de cursus de formation que les statisticiens eux-mêmes.
- Speaker #2
Et du coup, ça veut dire que ça a vraiment pris ce côté, on travaille même à la main en continu et en itération sur les besoins, les produits, les services qu'on veut développer ensemble, ou est-ce que ça c'était oui sur le papier et dans les faits, il y a toujours des problématiques RH, des problématiques de temps, des problématiques qui font que le modèle organisationnel a complexifié un petit peu la réalisation de cette envie.
- Speaker #0
Alors, il y a des tas de problèmes. Je dirais, le monde est loin d'être parfait. Typiquement, les métiers et les développeurs peuvent se comprendre, mais parfois, alors ça va être paradoxal ce que je vais dire, mais d'avoir trop la même culture, ça peut faire penser aux uns et aux autres qu'ils peuvent faire ce que ferait l'autre et donc penser à la place de l'autre, que ce soit l'informatique qui pense à la place du métier ou le métier qui pense à la place de l'informatique. Donc moi, je suis pour dire que si chacun est bien sur son rôle, ça fonctionne mieux. Déjà, il y avait une petite confusion à ce niveau-là. Et puis, inévitablement, l'agilité, on la met en place, mais en gagnant maturité, on s'aperçoit ce qui peut pécher, ce qui ne va pas forcément. Et typiquement, on a besoin et on y passe là actuellement, une piqûre de rappel sur tout ce qui est agilité.
- Speaker #2
Au niveau RH, le décloisonnement de l'organisation par silos, de manière historique ou même structurelle, ça s'est fait naturellement parce que comme tout le monde avait envie d'aller à l'égalité, il y a eu une envie aussi, je ne sais pas si on appelle l'administration, mais dans tous les cas des responsables, de donner du temps à l'ensemble des collaborateurs pour qu'ils aient le temps, en dehors de leur métier de statisticien, de pouvoir travailler main-à-main avec les équipes de la DSI. Ou est-ce que ça a été compliqué comme dans beaucoup d'entreprises parce qu'il y a une pression du quotidien sur faire les choses du métier là-dessus et donc du coup c'est du temps en plus ?
- Speaker #0
Alors c'est ambivalent. Il y a en effet une pression du quotidien pour faire de la production statistique comme on dit chez nous. Donc je dirais récupérer de la donnée, la corriger, la revoir, etc. Et qui peut être très franche sur certaines périodes. mais en même temps, il y a une conscience que c'est le métier qui doit savoir ce qu'il veut et qui doit guider toute l'agilité. Donc, il y a une vraie place donnée, je dirais, au rôle du métier quand il est défini comme étant le product owner d'un projet. Je ne dirais pas qu'il n'y a pas de pression opérationnelle, mais il y a un rôle connu et ce n'est pas à côté de son métier, c'est son métier d'être le product owner du projet.
- Speaker #2
Et c'est un mode vraiment ressources humaines dans l'administration. Peut-être que je connais mal aussi les préjugés. Il y a quand même une rigidité de la fonction. On ne modifie pas la fiche de poste d'un fonctionnaire. de claquement de doigts et en même temps c'est une modification de son périmètre de travail comment vous avez réussi à faire en sorte que ce soit faisable en fait de dire en fait t'es à 100% sur ton métier d'artiste là dans les prochains mois tu seras à 70% sur ton métier là mais t'auras 30% de ton temps sur la création de nouveaux services que la personne veut faire, ce n'est pas une question d'obligation, mais plutôt légalement, en termes de droit, comment ça s'est fait ?
- Speaker #0
Alors, les processus RH ont leur lourdeur, c'est clair, et en plus, on a un processus annualisé, donc des grandes campagnes de mobilité annualisées. Ça s'agit.
- Speaker #2
non c'est parce que je suis très âgé on est d'accord pour changer les projets pour itérer sur les produits les changements de personnes parce qu'en fait ça ça doit être sympa de réaliser ok je vois le truc et donc typiquement par contre typiquement quand
- Speaker #0
quelqu'un va être product owner sa fiche de poste est refaite et c'est même pas qu'elle est refaite c'est qu'il y a une fiche de poste qui est ouverte et ensuite candidate des gens sur cette fiche de poste pour être clairement institutionnalisé et productoneur donc il n'y a aucun sujet à ce niveau-là et les gens changent assez souvent de poste quand même on est sur
- Speaker #2
un 3-4 ans minimum et ça peut être plus ça peut être moins d'années je veux dire oui et donc du coup quand ils candidatent du coup ça veut dire qu'ils vont être à temps plein en temps de PO
- Speaker #0
ils vont avoir la mission. Alors, sur les projets vraiment importants, ils vont être à temps plein en tant que PO. Et sur d'autres projets, ils vont avoir une partie de leur temps qui va être clairement définie comme étant PO.
- Speaker #2
Donc, ça, vous arrivez à le gérer une fois par an parce qu'il y a cette rigidité-là. Mais globalement, une fois par an, ça marche assez bien. Et puis, dans l'année, quand il y a des petits soucis, forcément, c'est un peu plus compliqué.
- Speaker #0
Mais d'un autre côté, Je dirais que les gens à un certain niveau de responsabilité n'ont pas forcément des fiches de poste très précises et faites exactement en cordeau. Et donc, il peut y avoir une certaine souplesse à ce niveau-là.
- Speaker #2
Et donc, ça, c'est la partie H. Sur la partie, on va dire, structuration de votre target opérative modèle, votre termes à vous, c'est-à-dire la façon dont vous voulez travailler, un sein, etc. Comment vous l'avez ? pour créer, imposer, dessiner. L'agilité, c'est une chose. L'agilité, c'est des valeurs, c'est des principes. Après, il y a la façon dont on s'organise réellement au quotidien et que ce soit par semaine, par mois, par trimestre, les parties prenantes, etc. Et ça, il y a plein de frais morts. Il y a de l'artisanal, il y a du dogmatique. Comment vous le mettez en place et comment vous faites en sorte que les gens créent leur propre thème à eux ?
- Speaker #0
alors typiquement vous dites bon ok il y a les valeurs mais il y a plein d'autres choses etc moi j'inverserais la proposition quand même il y a plein de choses mais il faut toujours revenir aux valeurs et pour moi c'est absolument essentiel les quatre valeurs de l'agilité c'est vraiment la base et c'est ce qu'il ne faut pas perdre de vue et c'est ce qu'un certain nombre de frameworks à mon avis perdent de vue et c'est fort dommage donc la première chose c'est d'arriver à instiller une culture je ne sais pas si vous voyez ce modèle mais c'est quelque chose qui me plaît beaucoup c'est le modèle de l'iceberg Donc, on parle dans les transformations. Et en fait, tout en bas, il y a la vision, la culture, le truc le plus dur à changer en profondeur. Et c'est là que les valeurs vont vraiment changer cette chose en profondeur. Après, on peut faire de toutes sortes de façons. On peut avoir différents types de framework. Et je dirais, en fait, il faut surtout s'adapter en fonction de l'équipe et en fonction, par exemple, de la taille d'un projet. On ne va pas faire un projet avec une vingtaine de personnes comme on fait un projet avec deux personnes. donc ça c'est quelque chose de très important l'INSEE a une grande chance elle a une division, on appellera le centre agile de l'INSEE, même si c'est pas sa dénomination interne avec un certain nombre de coachs qui sont vraiment internes donc c'est pas avec de l'extérieur c'est des gens qui accompagnent les équipes, qui peuvent je dirais acquérir de l'expérience sur la façon dont ça se passe chez nous et donc transférer cette expérience d'une équipe à l'autre Globalement, nous, on s'est focalisés sur Scrum et Kanban parce qu'en plus, nous, on a plutôt beaucoup de petits et moyens projets que des gros. Parce qu'en fait, chaque track de je génère un certain nombre de stats ou je fais un certain nombre d'analyses etc. est relativement indépendant. L'adhérence est par les données, mais il ne va pas être tellement entre systèmes d'information. Donc, le modèle Scrum est assez souvent, je dirais, suffisant avec une équipe. Il y en a où on a été plus gros, mais c'est plus rare. Le Kanban, c'est plutôt quand on est en phase, je dirais, alors je vais faire bondir les agilistes, les vrais, etc., mais en phase de maintenance sur certaines choses. Parce qu'on ne gère pas tout en produit, on n'a pas les moyens de tout gérer en effort continu. Il y a des choses sur lesquelles on met les moyens en continu et on se concentre, par exemple, une filière d'enquête ou tout ce qui est communication institutionnelle, site web, etc. Mais il y a d'autres sujets où on fait un petit pic d'activité tous les cinq ou dix ans et puis après, on est gentiment maintenant. Là, typiquement, on va se mettre en mode combat, mais le faire en agilité quand même.
- Speaker #2
OK. Donc, fonctionnement de produit sur les produits cœur. Donc là, on a des équipes dédiées en continu. Là, on est sur du Scrum avec des itérations continues, etc. Par la valeur. focus client et ensuite on a on peut pas être un produit avec des équipes dédiées à temps plein sur tous les produits il y en a qui peuvent pas tout le monde et donc du coup c'est vrai c'est une question c'est aussi une question clairement de moyens et donc du coup là on est plutôt sur du camp priorisation de l'amélioration en fonction de certaines capacités qu'on veut y allouer de temps en temps ça c'est l'exécution on va dire produit projet comme on le veut en fonction mais ce n'est pas encore le modèle global d'organisation. Par exemple, comment on réaligne toutes les équipes, tous les X mois ? Quels sont les rituels communs ? Parce qu'on pourrait prévenir que chacun produit Scrum ou qu'un vent sur certains autres projets, on leur vit de leur côté, mais en fait, on a plein d'injoues de priorisation entre eux. Qu'est-ce qu'on ne fait pas ?
- Speaker #0
Il y a différentes réponses à ça. D'une part, comment on alloue des moyens ? Alors là, on est vraiment dans l'administration administrative. On fait un comité directeur de planification triennale des travaux.
- Speaker #2
C'est le nom.
- Speaker #0
voilà ok au moins ça pose le game ça pose le game exactement chaque année il y en a un grand qui alloue clairement des moyens à tel projet tel autre ou pas etc bon au moins ça a la qualité de trancher un certain nombre de choses même si c'est un process qui est assez lourd et qui demande énormément d'énergie à pas mal d'acteurs bon ça c'est je dirais les priorisations et en plus il y a un vrai partage à haut niveau de sur quoi on veut mettre la priorité. Après pour ce qui est des synchronisations d'équipe je dirais du travail commun comme je l'ai dit les projets sont quand même relativement indépendants et donc la synchronisation va plutôt se faire sur les façons de faire sur par exemple une démarche craft qu'on a en cours où on anime les différents centres de développement oui parce que ça je ne l'ai pas dit mais on a quatre centres de développement un à Nantes un à Lille un à Orléans et un à Paris et au total on a quand même près de 200 développeurs en interne sans externalisation donc ça fait une bonne puissance de tir Et donc, il faut animer ces compétences, être sûr de les maintenir à l'état de l'art. Donc, il y a toute une animation du développement qui est mise en place. et qui est plus, je dirais, sur la façon de faire et sur les compétences que sur les différents projets entre eux.
- Speaker #2
Du coup, les projets sont assez indépendants, donc du coup, on est plutôt sur des moments communs de partage de bonnes façons de faire et d'apprentissage, ok ? Mais du coup, par exemple, dans ce plan triennal de planification...
- Speaker #0
Proclamation triennale des travaux.
- Speaker #2
Proclamation triennale des travaux, excusez-moi, mais je n'avais pas eu le... le réflexe de retenir le nom parfaitement, il n'y a pas du coup, dans l'année, par trimestre, une repriorisation commune de voilà, il y a ça et ça qui ont changé. Au final, on s'est aperçu que ça, c'était plus compliqué ou des priorités peuvent être arrivées. Donc du coup, ce côté roadmap continue tous les trimestres de dire ok, on avait prévu de faire ça, ça, ça, mais en fait, on va plutôt faire ce genre de choses.
- Speaker #0
Alors évidemment qu'il y a ce genre de régulation qui est je dirais incontournable, mais c'est pour ça que quand je suis arrivé j'ai aussi insisté pour qu'on pilote les priorisations au niveau de la programmation triennale par enveloppe. Et donc pas projet par projet. mais par un certain nombre de projets qui vont être sur un domaine. Les statistiques culturelles d'entreprise, les statistiques démographiques, les logiciels de gestion interne, etc. Et donc, qu'on puisse en cours d'année, en permanence, arbitrer à l'intérieur de ces enveloppes, mais au niveau, je dirais, beaucoup plus local des centres de développement.
- Speaker #2
Donc, il y a des enveloppes de programmes qui correspondent à des axes stratégiques où tous les ans, il y a des budgets qui sont alloués là-dessus. Donc, c'est... En gros, une répartition d'un effort par rapport à un acte stratégique, mais à l'intérieur, la priorisation va être faite de manière plus agile avec les équipes. Quand on parle d'équipe de développement, donc là c'est... dans un axe donné, donc statistiques structurelles d'entreprise, il y a 40 initiatives, il y en a 10 de plus. Là, le choix se fait par les équipes à l'intérieur de ce programme de développement qui mélange les PIO, les métiers, etc.
- Speaker #0
On ne crée pas de nouveaux projets ex nihilo, sauf si c'est vraiment petit. Il y en a eu quelques-uns, genre deux, trois mois, c'est tout. Par contre, je dirais, on priorise et on organise l'effort qu'on veut mettre sur tel ou tel projet en fonction soit des allées des projets, soit, par exemple, d'une arrivée réglementaire, d'une obligation X ou Y qui nous tombe dessus.
- Speaker #2
donc il n'y a pas de notes qui sont intéressantes donc dans l'année dans un programme donné on n'a pas de nouvelle initiative qui peut rentrer sauf exception non et je dirais pour le coup c'est pas forcément très gênant dans
- Speaker #0
le domaine dans lequel on est parce que la mise en place d'enquêtes de statistiques etc a je dirais non pas pour des raisons informatiques mais pour des raisons plus métiers une certaine inertie donc mettre en place les panels qu'on va interroger s'assurer de la méthodologie pour ne pas faire d'erreurs etc prend un certain temps et sur la mise en place d'une enquête on peut être facilement sur plus de l'année voir certaines grosses enquêtes c'est trois ans pour les
- Speaker #2
construire et les mettre vraiment en place ok ça c'est les projets orientés clients finaux et métiers il y a des projets qui sont plus aussi tournés vers l'interne qui du coup peuvent être réunis
- Speaker #0
peut être des fois plus rapide c'est typiquement dans ce domaine là qu'on a des petits projets qui apparaissent de 3 mois et qui sont en effet sur l'enveloppe mais c'est en effet des cas atypiques ma question que j'avais posée il y a 10 minutes mais j'ai pas eu la réponse c'est comment ça s'est passé au tout début entre ok on a choisi en
- Speaker #2
fait vous m'avez dit deux choses il y a le plan annuel ensuite maintenant on décopose par programme ou par entité on va dire macro à l'intérieur on n'a pas de nouveaux beaucoup de nouveaux projets parce que Nos métiers ont des contraintes fortes pour que les projets puissent naître qui ne sont pas des contraintes IT au final, qui sont des contraintes métiers très bien. Et on va avoir des typologies de projets qui vont être un scrum parce qu'on peut avoir des équipes produits spécialisées et aussi beaucoup d'autres projets ou produits qui vont être plutôt en mode Kanban parce que là c'est plutôt de la maintenance un peu on va dire acyclique. Maintenant tout ça et la mise en musique de ça etc. Je ne sais pas moi, vous avez pris Framework, Safe, vous avez créé vous tout, quelqu'un l'a écrit en interne, en groupe. Il y avait un projet agile qui avait réussi, le scale de ça, l'uniformisation des pratiques, etc. Comment ça s'est né ?
- Speaker #0
Typiquement, c'est ce que j'ai dit avec le centre agile, c'est-à-dire que ça a été fait plutôt en interne et ça a été fait sur 10 ans par extension progressive des pratiques, des équipes les unes vers les autres. donc il n'y a pas eu un grand matin du grand soir où on a fait une bascule de trois semaines et puis voilà non non c'est une mise en place progressive sur dix ans et je dirais avec toute la complexité que ça a pu avoir je dirais d'embarquer les gens et on n'a pas un grand framework à la SAFE alors d'une part parce que comme je le dis étant donné que nos projets sont relativement indépendants Ce n'est pas forcément nécessaire. Et puis, pour être très honnête, moi, je ne suis pas convaincu par les grands framework qui arrivent avec leurs armées de consultants certifiés pour vous expliquer comment il faut faire dans votre vie. Alors que, bon, c'est un peu spécifique, à mon avis, aux gens qu'on a, à leur profil et à l'organisation.
- Speaker #2
Ok, et du coup, pour le matérialiser tout ce changement dans 10 ans, il faut le vendre aussi en interne, il faut l'expliquer, il faut que ce soit compréhensible. Vous avez fait des schémas, vous avez dessiné une cible, enfin une organisation cible, parce que l'organisation cible, ce n'est pas juste dire il y a des projets en Scrum, des projets en Kanban, nos tailles de sprint sont uniformisées là-dessus. il y a quand même beaucoup de nuances dans tout ça il y a beaucoup de détails qui font que les gens comprennent, n'ont pas peur voient pourquoi ça va les aider parce qu'en fait, indépendamment, on n'aime pas les frameworks safe, etc le côté positif, c'est que vous avez de la littérature et que vous n'êtes pas le seul à prêcher le modèle comme on vous disait avec des armées d'externes, prêcher le modèle que vous voulez porter et donc du coup à tous les niveaux de l'organisation quand vous ne faites pas appel à ce type de solution voilà parce que je parle solution, framework, plus consultant, plus littérature, plus lobby, du coup, le changement que vous voulez opérer, il n'a pas de nom, il est un peu difforme parce qu'on le contourait.
- Speaker #0
Il n'a pas de nom, si, justement, c'est ce que je disais, il se réfère essentiellement aux valeurs. et donc il a ses valeurs et il les met en avant et en plus vu que ça s'est fait lentement ça s'est fait aussi par démonstration des résultats et de ce que ça permettait donc typiquement on est passé d'un monde où les développements étaient je dirais du bon vieux cycle en V avec toute l'insatisfaction que ça pouvait générer et on est passé à quelque chose qui fonctionne beaucoup mieux et où le métier n'avait pas de difficulté à s'insérer. Là, on revient au fait qu'ils ont une culture numérique à la base. Parce qu'il ne faut pas se leurrer. Comme je dis toujours, l'agilité, ça marche mieux. Pourquoi ? Parce qu'on demande beaucoup plus d'efforts au métier.
- Speaker #2
forcément dit comme ça ça coûte plus cher non par contre ce que je dis je ne suis pas sûr que ça coûte plus cher enfin je ne suis pas sûr que ça coûte moins cher par contre le résultat est bien meilleur oui alors le ROI et le coût sont deux choses différentes mais par contre si on demande aux gens d'investir plus d'argent de temps dans le produit c'est souvent ça le pain principal c'est que il y a une non compréhension que pour que ça change, ça doit venir pas uniquement de la partie dev, mais aussi de la relation et du temps qu'on va louer ensemble. Et ça, ce côté one team n'est pas forcément compris à 100%. OK.
- Speaker #0
Mais là, pour le coup, dans la culture maison, c'était assez facile à faire comprendre.
- Speaker #2
OK. Résultats qui ont apporté une démonstration que ce qui est mis en place apporte de la valeur. On va dire un effort fort sur la pédagogie au niveau des valeurs de l'agilité. le socle culturel et ça ça a permis que sans s'appuyer sur un socle framework connu et de l'extérieur etc ça soit suffisant ok si demain vous devez le refaire dans une contrainte de temps plus serré parce que pression dans l'administration ou autre des gros changements forts à 3 ans à 2 ans voilà des contraintes on n'est pas à la semaine mais qui sont bas qui sont bas là-dessus comment vous y prendriez avec ce que vous avez appris là-dessus
- Speaker #0
Typiquement, là, moi, je suis dans ce que j'appelle la deuxième phase de l'agilité, c'est-à-dire qu'il y a une première phase qui a été faite avec certaines pratiques, etc., mais je pense qu'il y a une deuxième phase de maturité qui doit intervenir. Et là, pour le coup, j'aimerais bien qu'elle intervienne rapidement. Typiquement, pour ce type de sujet, ce que je vois bien, c'est la résistance, je dirais, de ce qu'on appelle l'encadrement intermédiaire, qui est bien classique. qui veut protéger, alors ce n'est pas forcément, je dirais, de la malignité ou autre, mais qui veut protéger les agents, les façons de faire, parce qu'elle pense que ça fonctionne à peu près et que si on chamboule tout, on risque de tout casser. Et donc, typiquement, je me concentrerai sur ce sujet-là, premièrement. Deuxièmement, si je devais déclencher l'agilité et convaincre les métiers, je pense que je ferais comme l'a fait l'INSEE, mais après avec une surmultipliée derrière, qui est de commencer par un projet emblématique en mettant les meilleurs dessus.
- Speaker #2
Le plus risqué, ou le truc que tout le monde va regarder avec les meilleurs, et là on trouve que ce n'est pas le quick win, c'est le best.
- Speaker #0
win avec la best team pour montrer que vraiment ça peut dépoter ok et ça a clairement eu cet effet là sur l'INSEE c'est à dire que ça reste quand même une référence ce projet ce projet risqué qui a été fait comme le premier projet agile donc ça je pense que c'était une bonne chose et ensuite après par contre je pense qu'il faut faire monter à peu près tout le monde en même temps si on veut être rapide, et pas essayer de, je dirais, mettre l'accent sur telle et telle chose et faire monter par petits groupes à fond, mais plutôt faire monter tout le monde en même temps. Ensuite, le framework, moi, je n'y crois pas. Ce qui a été vraiment une occasion de réussite à l'INSEE, c'est d'avoir un centre agile en interne. Donc, il faut avoir de l'apport de compétences externes par des coachs, mais il faut aussi avoir des gens qui n'ont aucun intérêt externe et qui sont vus comme de la famille. pour faciliter la montée ?
- Speaker #2
Donc, on commence avec un super projet, on met la meilleure équipe dessus, les meilleurs talents, ça devient une référence. Donc là, il y a un déclic qui se fait. Après, on ne va pas être dans une stratégie de cornerisation des équipes qui seront pas montées, etc. Mais on va essayer d'embarquer tout le monde pour éviter un delta trop important qui crée des rivalités, etc. Et ça, ça peut être fait avec une tactique de pôle de compétence en interne. Vraiment, ça passe par Internet, qui sort en mode, là, pour vraiment faire grandir les gens, leur expliquer, comprendre leur métier, leur... Ok, très clair.
- Speaker #0
C'est ça, c'est complètement ça.
- Speaker #2
Et du coup, entre la première phase de l'agilité, la première phase, c'est la phase de 10 ans ou c'est les 3 dernières années ?
- Speaker #0
La première phase, c'est les 10 ans, je dirais. moi j'appelle la première phase avant que j'arrive parce que je ne peux pas décomposer ce qui s'est passé avant je n'en ai pas suffisamment la connaissance et la vision mais il y a une montée assez douce pour tout dire, quand en 2021 dans un papier officiel ou autre je ne sais plus, j'ai mis que tous les projets étaient en agile au comité directeur il y a des directeurs qui m'ont dit, ah bon ? on ne savait pas ça n'avait jamais été dit mais pas on est contre c'est voilà on ne savait pas bon voilà il pensait qu'il y avait encore des trucs qui vivotaient en cycle en V c'était plus le cas et du coup par rapport entre la première et la seconde phase le côté management intermédiaire qui veut voilà qui a peur pour que les agents soient déboussolés ou autre ou que ça crée la difficulté à l'internet ça n'a pas été un frein massif initial à la phase 1 c'est à dire que ça a pu quand même se faire à la phase 1 parce que ça s'est fait sous le radar quelque part ça s'est fait assez doucement
- Speaker #1
10 ans c'est quand même long
- Speaker #0
ouais mais du coup il y a quand même en dehors de sous le radar il y a quand même des fiches de poste par exemple un manager si un gars de son équipe il a appelé il a le candidat à pio un tiers de temps sur un tel produit ça se voit quand même ouais mais ça c'est fait par adhésion progressive donc
- Speaker #1
sans difficulté particulière ok c'est rentré dans la pratique c'est le coup de la grenouille alors c'est quoi le coup de la grenouille ? une grenouille qu'on met dans une casserole d'eau froide on met le feu en dessous Elle va finir morte et bouillantée. Une grenouille qu'on jette dans une casserole d'eau bouillante, elle va sauter hors de la casserole.
- Speaker #0
Ok, d'accord, je donnerai cette image à des managers et des directeurs. Donc en fait, pour dire un peu...
- Speaker #1
Non, mais si on veut faire plus positif, c'est que globalement, il y a eu une appropriation progressive, il n'y a pas eu de heurts, il n'y a pas eu de chocs.
- Speaker #0
Mais maintenant, ils se rendent compte quand même du truc. Quand ça fait sur trois ans, les trois dernières années, tu as trois grades chez eux qui petit à petit sont devenus piois de certains, piois de d'autres. Et qu'ils ont eu des difficultés dans leur métier à faire ce qui devait être fait, à compenser à je ne sais pas quoi. En fait, là, ils y sont. là nous on a donné du temps etc mais ça nous a créé x, y, z de complexité et là du coup ils commencent à conscientiser à formaliser une forme d'opposition en disant en fait on n'est pas gagnant à 100% de cette façon de faire là donc c'est leur perception des choses et donc du coup c'est là où il peut y avoir une opposition on
- Speaker #1
n'a pas dû bien se comprendre en fait Quand je parlais de résistance dans l'encadrement intermédiaire, c'était plus de l'homéostasie, c'est-à-dire on est dans un mode agile qui va à peu près, donc pourquoi essayer d'améliorer nos pratiques, pourquoi avoir un deuxième niveau de maturité, parce que moi ce que je porte en effet, c'est qu'il y a toute une série de pratiques qui ne sont pas complètement matures. donc il y a certains patterns qui ne sont pas en place par exemple les specs c'est plus ou moins abandonné on a des US qui tournent au spec parfois, donc comme je le dis à certaines équipes, vous faites du cycle en W mais vous ne faites pas de l'agile c'est à dire des petits cycles un derrière les autres bon, alors pas partout, pas dans toutes les équipes mais ça existe on a des équipes où la rétro est vue comme quelque chose d'inutile donc comment on améliore ces pratiques j'ai du mal à le savoir voilà bon c'est toutes ces choses là
- Speaker #0
Ok, donc moi je pensais que c'était une prise de conscience des métiers qu'il y avait une difficulté. Non, c'est dans les équipes agiles, c'est le challenge de, bon on a fait un truc qui est cool et tout ça, mais par contre on va reprendre les bases, certaines bases en tous les cas, et ce n'est pas homogène sur toutes les équipes pour vraiment nous améliorer. Et là c'est plutôt une opposition, un frein à l'amélioration continue de leur pratique tout simplement. c'est plus ça en effet est-ce que vous avez mis c'est bête à dire mais des fois l'inspiration d'équipe d'autres entreprises ou d'autres administrations sur leur pratique et pourquoi, comment vous abordez cette pratique là, est-ce que vous avez déjà votre compétence en interne ils les connaissent, ils se connaissent etc il y a un biais aussi de personnes là-dessus sur l'inspiration
- Speaker #1
quand on va sur l'extérieur on est plus facilement inspiré par les gens qu'on ne connaît pas c'est bête mais le centre de compétences pousse les gens à aller à des conférences on achète des lots de places sur un certain nombre de conférences pour que les gens puissent y aller que ce soit des devs ou des métiers d'ailleurs après on a toujours un peu le même problème c'est que c'est les meilleurs qui regardent ailleurs et donc qui enrichissent encore leurs compétences alors que d'autres restant sur leur train-train ne vont pas forcément chercher à s'ouvrir les chakras comme on dit ici
- Speaker #0
c'est du c'est du classique c'est bête à dire mais c'est du classique people management comment on fait grandir d'accord donc ça c'est phase 2 et au niveau de la direction avec son acronyme de plan annuel est-ce qu'il y a un besoin de formation besoin de changement au niveau de l'agilité de comprendre certaines choses ou pas ?
- Speaker #1
justement dans les 10 ans il y a eu Il y a eu aussi le temps d'infuser vers le haut. Donc, l'ensemble de la structure a une vision tout à fait correcte de l'agilité. Alors, je dois dire aussi que l'INSEE, pour moi, c'est un petit bonheur de ce côté-là, c'est qu'il y a une culture d'ingénieur du haut en bas de la pyramide. Donc, ça facilite énormément ce genre de dialogue et ce genre de montée en compétence à tous les niveaux.
- Speaker #0
Et par exemple, je ne sais pas si c'était courant à l'INSEE ou dans le type de direction, mais les membres, je ne sais pas si c'est un président, un directeur général, ils s'intéressent aux détails de certains projets, ils viennent des fois sur des rétrospectives et ce qu'ils font partie prenante de l'intérieur des projets, dans les programmes, pour voir comment ça se passe, pour comprendre, ou pas du tout.
- Speaker #1
Alors, les directeurs eux-mêmes sont sponsors et actifs sur un certain nombre de sujets, en particulier les produits dont on parlait, c'est-à-dire les choses sur lesquelles on veut mettre un effort continu. Et d'ailleurs, ça c'est le côté aussi positif du fameux programme triennal des travaux, c'est que chaque année, je dirais, les directeurs vont défendre quelque part tel ou tel projet, vont défendre les moyens associés. et donc s'investissent vraiment dans tous ces sujets-là. Mais aussi, on continue au cours de l'année, par exemple sur le produit filière d'enquête, qui est quelque chose d'important. On a quand même trois directeurs métiers et moi-même qui sont régulièrement impliqués tous les mois sur un certain nombre de sujets, avec retour aux équipes, etc.
- Speaker #0
et dans les équipes qui font les rétrospectives sur les améliorations etc est-ce que vous vous êtes impliqué les directeurs aussi ou pas ?
- Speaker #1
Alors sur les rétrospectives non parce qu'on considère évidemment que les rétrospectives c'est un moment de l'équipe sur son propre comportement son propre fonctionnement et qui peut aussi être l'occasion de mettre en évidence tous les dysfonctionnements et on fait ça entre soi en général par contre il peut y avoir des moments spécifiques qui sont plutôt, je dirais, de l'ordre de ce qu'on pourrait appeler un programme incrément. Alors, pour le coup, je prends une notion safe là, c'est-à-dire, je dirais, plutôt à une période de tous les deux, trois mois où on se retourne, on regarde ce qui a été fait et on regarde pour la suite ce qu'on a fait. Et là, éventuellement, sur certains sujets, ça peut monter jusqu'au directeur.
- Speaker #0
et au niveau on va dire de ce que vous allez mettre en place en dehors du du nivellement par le haut des pratiques etc des équipes est-ce qu'il y a d'autres enjeux si celui-là vous le faites on va dire si la phase 2 vous arrivez un peu plus rapidement c'est quoi la vision que vous avez sur la phase 3 pour faire en sorte que l'INSEE soit encore encore meilleure c'est même pas une phase 3 c'est une phase 2 bis parce qu'elle est en route en parallèle c'est la mise en place du DevOps Parce que du coup, DevOps, ce n'est pas encore dans les pratiques d'agilité. Vous n'avez pas pu mettre le DevOps en place.
- Speaker #1
Ça, c'est un des problèmes qu'on a. C'est qu'en même temps que l'agilité était mise en place du côté des devs, au contraire, il y a un renforcement process utile du côté des ops. et donc il y avait une espèce de hiatus entre les deux mondes avec un monde très très processé du côté des Ops très tiquété et tout et tout et un monde qui s'assouplissait du côté des devs Donc, quand je suis arrivé, je me suis rendu compte de ce problème.
- Speaker #0
Les OPS chez vous, c'est juste pour être sûr, parce que les OPS...
- Speaker #1
Les exploitants la prod.
- Speaker #0
Ok, c'est vrai. Ok, d'accord.
- Speaker #1
Et donc, quand je suis arrivé, j'ai vu ça, mais on avait en cours un énorme chantier de changement de centre d'hébergement, parce que tout l'hébergement est fait en interne à l'INSEE. Et donc, il a fallu différer un peu ce sujet-là. Et donc, on s'y attelle depuis un an là maintenant et on va faire la bascule DevOps là sur l'année. Donc, en réorganisant complètement les équipes, en les mettant en équipe service et non plus en silos de compétences comme ils étaient actuellement.
- Speaker #0
Ok, et ça du coup, ça n'a pas été un vrai gros frein à l'agilité pour pouvoir vraiment être agi sur la partie produit ?
- Speaker #1
Si, si, parfois certaines équipes agiles ont attendu plus de six semaines un environnement.
- Speaker #0
L'enfer !
- Speaker #1
Voilà, l'enfer.
- Speaker #0
L'enfer, oui. Et les push en prod c'était la même chose ou après à partir du moment où c'était stacké ça allait ?
- Speaker #1
après ça allait quand même faut pas peindre les choses en noir l'organisation fonctionnait et tout et tout mais il y avait clairement un manque de souplesse sur un certain nombre de sujets
- Speaker #0
ok et donc du coup une grosse phase de bis avec pas mal de risques associés j'imagine bien intéressant c'est hors de contexte mais vous avez dit c'est un interne on imagine bien l'enjeu des datas mais pourquoi pas passer chez un scaleway ou un VH un mode opérateur français c'est une question de coûts, de compétences de données régaliennes
- Speaker #1
Alors, pour l'instant, on a vraiment un sujet donné régalien. Et comme je l'ai dit, on a changé notre centre de prod sur les années 2020-2021. et donc on a tout refait à neuf du sol au plafond et à cette époque-là je dirais qu'il n'y avait pas une poussée aussi forte vers le cloud au niveau de l'État et donc ça nous donne 3-4 ans pour avoir une nouvelle stratégie sur le cloud parce que vu qu'on a des serveurs super puissants on n'a pas intérêt à les acheter en plus de la puissance de calcul ailleurs et donc je dirais c'est en 2025 qu'il faudra revoir cette politique. Ceci dit pour être honnête, il ne faut pas oublier que l'INSEE, par exemple, c'est le fameux RNIPP, le registre des personnes privées qu'on appelle le numéro de sécu, d'habitude. En fait, c'est l'INSEE qui le tient. Et ce genre de choses, c'est une base sur l'ensemble des Français.
- Speaker #0
Oui, on va éviter de faire des trucs un peu open. Je vois bien le truc.
- Speaker #1
Donc, tout n'est pas de ce niveau-là. Il y a des choses qu'on va pouvoir mettre sur le cloud, mais il faut faire attention.
- Speaker #0
Oui, en fait, c'est au final, c'est aussi comme Michelin qui dit qu'il y a plein de données, soit des calculs très coûteux, soit des données tellement confidentielles qu'ils préfèrent les avoir en interne et gérer ça. Et puis, il y a plein d'autres produits où au final, ils peuvent les avoir dans le cloud et avoir. C'est une question d'hybride et de bien séquencer ça. OK,
- Speaker #1
très clair. et en externe du coup on se met aussi à avoir une infra Kubernetes enfin donc on a des techno cloud en interne et donc on pourra passer sur un certain nombre de choses sans trop de difficultés en externe on arrive à la fin est-ce qu'il y a un point quelque chose qui vous semble important qu'on aurait ou intéressant qu'on n'aurait pas abordé qu'on n'a pas abordé non mais je vais insister lourdement parce que pour moi c'est quelque chose qui est très très cher c'est de revenir aux fondamentaux des cas de valeur et de s'interroger sur toutes ces pratiques en agilité si on est conforme à ces quatre valeurs. Et en particulier avec la quatrième valeur qui est l'adaptation plus que le respect du plan, qui à mon avis est une méta-valeur, c'est-à-dire que ça s'applique même au framework par exemple, c'est-à-dire qu'un framework, plutôt que de se dire est-ce que je respecte le framework, non, c'est est-ce que je suis adapté, est-ce que ça va bien. Et donc en permanence se réinterroger sur ces pratiques à partir de ces valeurs.
- Speaker #0
ok c'est le point le point important dans la façon de faire qui est très cool très bien écoute c'était super intéressant si on a des délices qui soient dans l'administration ou dans le privé qui sont intéressés pour échanger avec vous ils peuvent vous contacter sur LinkedIn sur la partie agilité etc c'est ok ?
- Speaker #1
tout à fait pas de problème
- Speaker #0
bon top et du coup pour information quand vous écouterez le podcast normalement je pense que la conférence de Jean-Séverin sur Agile en scène sera sortie aussi en replay et ça peut être intéressant on n'y aborde pas forcément les mêmes sujets de la même manière mais du coup c'est un complément et c'est aussi riche ça peut être intéressant peut-être qu'on mettra le lien dans la description quand ça sera sorti bon merci pour tout c'était super intéressant et bien merci beaucoup
- Speaker #2
Bon, j'espère que vous avez adoré ce podcast comme nous. C'est super intéressant de pouvoir poser toutes ces questions et vraiment aller au fond des choses. Pour aller encore plus loin, on lance un cycle de live, un vendredi sur deux, du coup entre 13h et 14h, ou entre 11h et midi. Donc pour vous inscrire, soit vous suivez sur LinkedIn où vous verrez les événements passés, soit vous allez sur rsas.io et vous aurez tous les événements qui vont sortir. Donc n'hésitez pas, dans ces lives, vous pouvez poser vos questions. et intervenir directement avec le speaker. Et en attendant, bien sûr, n'hésitez pas à partager le podcast sur LinkedIn et à le noter sur Apple Podcasts ou Spotify. Merci à tous.
