En 2022, nouveau changement de décor : il rejoint FUZYO comme Business Analyst.
Quelques années plus tard, le voilà Product Manager au sein d’une grande organisation publique belge, où il pilote aujourd’hui une équipe de huit personnes.
Il découvre rapidement que ses nouveaux projets IT répondent à une logique bien différente de celle qu’il connaissait dans la banque.
« J’ai compris pourquoi il y avait autant de différences entre le public et le privé »
C’est probablement l’un des principaux enseignements que Didi tire aujourd’hui de cette mission. Lorsqu’il travaillait pour des banques, le cadre était fortement rythmé par le time-to-market. Les délais étaient précis et la sécurité constituait une priorité absolue. Les projets répondaient à des objectifs clairement identifiés et les utilisateurs étaient généralement déjà très familiers des outils informatiques.
Dans le public, Didi découvre d’autres contraintes.
« Il y a beaucoup plus de procédures dans l’organisation en amont que dans la réalisation des projets. »
Validations, réglementation, contraintes institutionnelles… Avant même d’arriver à la réalisation technique, le projet doit franchir plusieurs étapes. Mais ce qui l’a également frappé, c’est l’échelle.
Une solution bancaire sur laquelle il travaillait pouvait concerner 200 000, 400 000 ou 500 000 utilisateurs. Dans le secteur public, une solution peut potentiellement concerner… l’ensemble de la population d’un pays. Et cela change forcément la manière d’aborder le projet.
- La sécurité : même priorité, équation différente
Après plusieurs années dans le secteur bancaire, Didi avait l’habitude d’environnements où la sécurité informatique bénéficie d’investissements considérables. C’est logique : lorsqu’une organisation gère l’argent de centaines de milliers de personnes, la moindre faille peut avoir des conséquences immédiates.
Mais son arrivée dans le secteur public l’amène à regarder cet enjeu autrement.
Les organisations publiques détiennent elles aussi des informations extrêmement sensibles sur les citoyens. La sécurité y est donc tout aussi critique, mais sa mise en œuvre doit composer avec une autre réalité : procédures administratives, budgets publics, contraintes réglementaires et coûts importants liés à chaque évolution.
Pour Didi, c’est l’un des exemples qui montrent le mieux pourquoi comparer directement l’efficacité du public et du privé peut être trompeur. Les objectifs peuvent être similaires. Les conditions pour les atteindre ne le sont pas.
- Quand les utilisateurs ne parlent pas forcément IT
Autre changement important pour Didi : la relation avec les utilisateurs.
Dans une banque, il travaillait avec des collaborateurs habitués aux outils numériques et capables, la plupart du temps, d’exprimer assez précisément leurs besoins.
Dans son environnement actuel, il échange avec des métiers beaucoup plus opérationnels. Leur expertise est ailleurs. Ils connaissent parfaitement leur réalité de terrain, mais pas nécessairement les contraintes ou le vocabulaire de l’IT.
Pour Didi et son équipe, il faut donc aller plus loin que la demande exprimée.
- Comprendre le métier.
- Identifier le besoin derrière la demande.
- Puis réussir à le traduire en solution informatique.
Sa casquette de Product Manager prend ici tout son sens : il ne s’agit plus seulement de faire avancer une solution, mais de créer un pont entre des personnes qui ne parlent pas toujours le même langage.
- « Tout centraliser » ? Pas forcément
En arrivant dans une grande organisation publique, Didi découvre également une architecture très différente de celle qu’il connaissait. Là où une banque peut construire son organisation informatique autour de grands programmes fortement interconnectés, son environnement actuel fonctionne davantage comme un écosystème.
De petites applications spécialisées communiquent entre elles grâce à des API. Et cette dispersion n’est pas nécessairement un défaut.
Certaines directions n’ont, par exemple, aucune raison d’accéder aux mêmes informations que d’autres. Les bases de données peuvent donc être volontairement séparées pour préserver les besoins, les responsabilités et le savoir-faire propres à chaque métier.
À cela s’ajoutent les interconnexions avec de nombreux services externes : justice, mobilité, transports, télécommunications… Didi découvre alors un système où la complexité informatique reflète directement la complexité de l’organisation qu’elle sert.
Et en Belgique, une couche supplémentaire s’ajoute : celle des différents niveaux de pouvoir et des réalités régionales. Certaines solutions peuvent émerger localement, en Wallonie ou en Flandre, quand d’autres projets nécessitent au contraire une approche centralisée.
- Son projet : automatiser un processus qui concerne tout le territoire
C’est justement sur l’un de ces sujets transversaux que Didi travaille aujourd’hui. Son projet concerne l’automatisation d’un processus de vérification d’antécédents nécessaire pour certaines demandes de sécurité concernant des personnes. Cela peut notamment intervenir lorsqu’une personne doit accéder à certains environnements ou activités particulièrement sensibles, dans des secteurs comme le nucléaire ou les infrastructures critiques.
Dans ce cas, la logique change : le besoin concerne potentiellement l’ensemble du territoire et nécessite donc une gestion beaucoup plus centralisée de l’information.
Pour Didi, ce projet est un bon exemple de l’équilibre permanent à trouver dans une grande organisation publique : savoir ce qui gagne à rester spécialisé et local, et ce qui doit au contraire être pensé de manière globale. Développer aujourd’hui pour une règle qui peut changer demain
Mais le plus grand changement pour Didi se trouve peut-être ailleurs : dans la relation au temps.
Dans la banque, il avait connu des environnements où certaines échéances étaient respectées à la seconde près.
Dans le public, il découvre une temporalité beaucoup moins linéaire.
La législation évolue. Le Code pénal change. Une décision institutionnelle impose une nouvelle règle. Un délai arrive depuis un ministère.
Et soudain, le projet doit s’adapter.
Pour les équipes informatiques, cela signifie parfois devoir comprendre très rapidement une évolution réglementaire avant même de pouvoir déterminer comment la traduire techniquement.
« On n’a pas toujours de visibilité globale sur les délais et les coûts. »
Pour quelqu’un venant du secteur bancaire, le changement a demandé un vrai temps d’adaptation. Mais il lui a aussi permis de comprendre ce qui lui paraissait auparavant difficilement explicable.
Pourquoi certains projets publics prennent-ils davantage de temps ? Pourquoi une roadmap peut-elle soudainement évoluer ? Pourquoi certaines décisions semblent-elles arriver tardivement jusqu’aux équipes IT ?
En vivant le système de l’intérieur, les réponses deviennent beaucoup plus évidentes.
- Apprendre à travailler dans un « chaos organisé »
Un projet avance. Puis il change de priorité. Il s’arrête.. et revient quelques mois plus tard.
Pendant ce temps, les interlocuteurs peuvent avoir changé et de nouvelles contraintes être apparues. Didi a même connu plusieurs changements de direction sur certains sujets en relativement peu de temps.
Pour lui, cette mission est devenue une véritable école de la flexibilité. Au fil des projets, il a appris à ne plus envisager la gestion de projet comme une trajectoire parfaitement linéaire. En tant que Product Manager et chef de projet, il doit garder suffisamment de structure pour faire avancer son équipe, tout en restant prêt à revoir rapidement ses plans.
Une sorte de « chaos organisé » auquel il s’est progressivement adapté. Et qu’il considère aujourd’hui comme une expérience particulièrement formatrice. Car s’il devait demain retourner dans un environnement privé, il pense que cette capacité à travailler avec l’incertitude lui donnerait une flexibilité supplémentaire.
Après avoir appris à gérer des changements rapides et parfois imprévisibles, retrouver du stress dans un environnement plus structuré lui semblerait probablement… beaucoup plus simple à appréhender.
- Et puis, il y a la Belgique.
Heureusement, le quotidien de Didi n’est pas fait que de réglementations, d’API et de changements de roadmap. Il y a aussi la découverte d’une nouvelle culture de travail.
Aujourd’hui, il pilote une équipe de huit personnes particulièrement multiculturelle : Belges francophones et néerlandophones, Libanais, Italien, Mauricien… Didi ne parlant pas néerlandais, tout ce petit monde travaille principalement en anglais.
Un changement après ses expériences en Afrique francophone et avec des banques françaises. Mais ce qui l’a peut-être le plus amusé en arrivant en Belgique, ce sont les codes professionnels. Au Maroc comme en France, il avait connu des environnements où la présentation vestimentaire comptait : chemise, costume, tailleur…
En Belgique ?
« On peut venir travailler en short et en tee-shirt. »
Au-delà du dress code, Didi observe surtout une certaine flexibilité dans la culture de travail. Dans son environnement actuel, l’attention est davantage portée sur le service rendu et la satisfaction de celui qui le reçoit, qu’il s’agisse d’un utilisateur interne ou, indirectement, d’un citoyen.
Son équipe est également relativement jeune pour le secteur public, avec environ 32 ans de moyenne d’âge.
Résultat : une communication assez directe, une ambiance détendue et une diversité culturelle qui lui rappelle finalement certains aspects de ses expériences professionnelles en Afrique.
- Devenir consultant, c’est aussi apprendre à changer de lunettes
Depuis 2017, Didi aura finalement connu plusieurs vies professionnelles. Le développement, puis le consulting. Le Maroc, plusieurs pays africains, puis la Belgique.
La banque, puis le secteur public. Business Analyst, puis Product Manager et chef de projet.
Et chaque nouvel environnement l’a obligé à revoir certaines de ses certitudes.
Son expérience dans le public lui a notamment appris quelque chose d’essentiel : une méthode qui fonctionne parfaitement dans un environnement n’est pas nécessairement transposable telle quelle dans un autre.
Avant de chercher à optimiser une organisation, encore faut-il comprendre ses contraintes. Avant de juger sa vitesse, comprendre ce qui la ralentit. Avant d’appliquer une méthode, comprendre les personnes qui vont devoir l’utiliser.
C’est peut-être là que se trouve finalement le vrai fil rouge de son parcours chez FUZYO : apprendre à entrer dans un nouvel écosystème, en comprendre les règles et adapter sa manière de travailler sans perdre de vue l’objectif.
Parce qu’entre le public et le privé, les règles du jeu changent. Et pour Didi, apprendre à jouer sur les deux terrains est probablement devenu l’une de ses plus grandes forces.
