Il y a quelques mois, je quittais une scale-up ayant des dizaines d’employés et d'employées pour rejoindre Latitudes.

Latitudes est une équipe de 15 personnes à l’heure où j’écris ces lignes et est comme vous le savez sans doute… une association !

Ce changement a amené de nombreuses surprises et beaucoup de découvertes pour moi, en particulier dans l’exercice des métiers de la tech et du produit.

Cet article est une synthèse de mes apprentissages et de mes découvertes !

‍

Contexte / qui suis-je ?

‍

Je m’appelle Nicolas, j’ai 33 ans et je suis depuis janvier responsable de la tech et du produit chez Latitudes, une association qui a pour but de réinventer le monde la tech en le rendant plus engagé et plus responsable.

Ma mission chez Latitudes est la suivante :

• Élever et stabiliser la qualité de nos produits (outils internes de gestion de nos programmes, sites et applications…)
• Améliorer nos produits pour que leur efficacité permette à l’équipe de Latitudes d’atteindre ses objectifs d’impact
• Identifier et initier des opportunités pour que notre produit puisse être la source de nouveaux usages dans l’association (visualisation de données, gestion de la communauté, etc.)

‍

J’ai travaillé pendant environ 5 ans en tant que développeur puis un peu plus de 6 ans dans les métiers du Produit (Product Owner, Manager, …).

L’environnement dans lequel j’ai évolué est double :

• Au niveau professionnel très largement dans des start-ups et des structures ayant autour de 100 employés et employées, avec une ou plusieurs équipes de développeurs et développeuses, dans des secteurs divers.
• Par ailleurs j’ai eu l’occasion de faire du bénévolat et du mécénat de compétences (en tant que Product Manager majoritairement) dans plusieurs structures associatives, principalement l’ADIE et le Secours Populaire (fédération de Paris)

‍

tl:dr

‍

Les éléments principaux de surprise que je développe dans l’article sont :

• L’usage massif d’apps no code en production et ses conséquences sur la tech / le produit.
• La multiplication des outils cloud dans une structure pourtant peu technique.
• La relation (très différente de ce que j’ai connu) entre les équipes et la tech / le produit.
• Les objectifs majoritairement liés à l’impact et les contraintes liées aux valeurs d’une association à but non lucratif.
• La qualité de l’outillage open source disponible pour les associations.

‍

Les apps no-code

‍

C’est la surprise principale : l’usage massif du no-code pour la gestion de bases de données et l’applicatif en ligne.

Ayant travaillé toute ma carrière avec des équipes de développeurs, j’ai été très peu exposé au no-code pour créer des applications.

A l’inverse c’est un choix qui semble très naturel pour des petites associations comme Latitudes qui n’ont pas - au démarrage du moins - les moyens d’avoir une équipe technique ou de payer beaucoup de prestations.

‍

Si je devais résumer mon impression sur l’usage du no-code dans une structure : c’est un excellent choix pour lancer un programme associatif, si on sait s’arrêter au bon moment.

De manière intéressante, les problématiques qui freinent aujourd’hui Latitudes sur le plan technique (faible mutualisation des méthodes entre programmes, duplication de la donnée, saturation des bases avec une donnée très hétéroclite, …) sont des problématiques assez classiques… pour les développeurs et développeuses. 😅

C’est ironique mais il me semble qu’en allant trop loin dans l’usage en production d’outils no-code on se retrouve avec des problématiques de code… que ces outils ne sont pas en mesure de résoudre par design ! On ne règle pas des problèmes de code sans code. 🤯

‍

J’ai aussi découvert un enjeu fort vis à vis de l’équipe quand on utilise autant les outils no-code.

Les personnes ayant un profil entrepreneur / couteau suisse semblent adorer ces outils, qui permettent théoriquement de tout construire et de prototyper énormément d’usages. À l’inverse les personnes n’ayant pas cette sensibilité peuvent vite se retrouver écrasées par la complexité qui se crée à force d’aligner les prototypes.

Et cette dynamique semble s’amplifier avec le temps :

• parce que continuer à utiliser des outils no-code trop longtemps en production impose de les pousser de plus en plus dans leurs limites et donc de les rendre de plus en plus difficiles à utiliser
• parce que naturellement une structure qui grossit ne va pas recruter que des couteaux suisses, mais aussi chercher à développer des expertises plus spécifiques ! Et donc accueillir des personnes moins immédiatement à l’aise avec les outils no-code

‍

Il y a donc - je crois - une bascule nécessaire à opérer à un moment précis de la croissance d’une structure, pour aller vers un peu plus de code.

J’ai donc le sentiment que mes structures précédentes comme Latitudes vivaient dans un extrême problématique vis à vis du no-code :

• Les équipes tech avec lesquelles j’ai travaillé n’ont sans doute pas suffisamment utilisé le no-code pour prototyper très vite des applis quitte à les refaire plus tard au propre, ce dont elles avaient les moyens
• Une structure comme Latitudes est peut être restée un peu trop longtemps dans le no-code généralisé, au risque de rendre la situation difficile pour les équipes et de complexifier la bascule

‍

Les outils cloud “clés en main”

‍

Ce point est plus technique mais j’ai également été très surpris du nombre d’outils utilisés chez Latitudes.

J’ai retrouvé certes beaucoup d’outils “transverses” comme Notion, Figma et autres qui sont énormément utilisés dans les start-ups et scale-ups, mais Latitudes utilise aussi beaucoup de petits outils au cœur de son socle applicatif, pour ne citer qu’eux :

• TypeForm pour compenser certains défauts des formulaires AirTable
• WhaleSync pour faire de la synchro entre une BDD classique (Supabase) et AirTable
• ChiliPepper pour compenser certaines fonctionnalités manquantes aux pages Notion

‍

En apprenant l’historique de Latitudes, j’ai découvert qu’une bonne partie de ces outils ont été installés “dans l’urgence”.

Un nouveau besoin est apparu qui dépassait le cadre des outils no-code, ou un bug est venu bloquer certains usages, et dans les deux cas on ne disposait ni du budget ni de l’équipe ni du temps pour contourner proprement le problème. Il a donc fallu prendre un produit “sur l’étagère” qui compensait ce besoin précis.

‍

Cette approche a de nombreux défauts :

• La complexité d’avoir toute une constellation d’outils formant le produit d’une structure :
  • complexité administrative (échanges avec le support, facturation, …)
  • difficulté pour comprendre, débugger ou documenter tout ce qu'il se passe…
• Mais aussi des coûts potentiellement importants et peu rationalisés sur le long terme :
  • au gré des évolutions du prix de chaque outil
  • parce qu’en choisissant un produit dans l’urgence on se retrouve souvent à n’utiliser qu’une quantité limitée de ses fonctionnalités (et donc on n’en tire pas toute la valeur)

Ces outils, que je retrouvais moins dans mes jobs précédents où les “rustines” étaient codées, sont à la fois un poids et un risque important pour Latitudes !

Spoiler : ils ont quasiment tous été supprimés pendant ma mission.

‍

La relation entre les équipes non tech et la tech / le produit

‍

Cela peut sembler très étrange, mais le niveau de confiance que l’équipe m’accorde chez Latitudes est extrêmement déstabilisant pour le PM que je suis, formé à l’école des start-ups.

Dans toutes mes expériences précédentes, le métier de PM a été un sport de combat !

Il fallait aligner des personnes aux objectifs très différents (commerciaux vs opérationnels par exemple), manœuvrer avec des fondateurs et fondatrices d’entreprises qui avaient un avis très tranché sur “leur” produit, etc.

Et donc par construction, un bon PM de start-up / scale-up est pour moi un PM ayant une capacité très forte à convaincre, communiquer, adapter sa proposition de priorisation et créer un alignement fort qui ne s’effrite pas dès qu’une nouvelle idée émerge.

C’est presque sa raison d’être.

‍

Chez Latitudes, au delà de l’aspect “petite structure”, les challenges des collègues sont moins vindicatifs, et la confiance accordée “par défaut” au PM est beaucoup plus forte.

Cette bienveillance questionne mes réflexes :

• est-ce vraiment la peine de faire une présentation léchée pour convaincre si ma seule expertise est déjà convaincante ?
• dois-je vraiment aller chercher de la data si l’équipe se contente d’une explication plutôt que d’une démonstration ?

Il faut bien le dire, j’ai souvent pesté en entreprise contre des partis prenantes qui ne prenaient pas assez en compte l’expertise de leur équipe.

Et pourtant, je me rends compte aujourd’hui que ce qui a construit ma capacité à prioriser en confiance ce sont bien ces challenges extrêmes (et parfois même violents !) de mes propositions…

‍

Au final je prends le parti de garder mon niveau d’exigence malgré cette confiance, de me dire que je dois être en quelque sorte mon premier critique. Mais former une personne plus junior dans cet environnement poserait je pense de nombreuses questions, notamment pour transmettre les raisons et l’intérêt de cette exigence !

‍

Une structure guidée par l’impact et sous contraintes de ses valeurs

‍

Ce n’est pas une vraie surprise, et c’est même une des raisons pour lesquelles j’ai souhaité tenter l’aventure du Produit dans une structure associative, mais travailler dans une structure dont l’objectif principal est son impact positif est… rafraîchissant !

Pour être honnête l’effet sur mon travail n’est pas aussi “direct” que je pouvais l’imaginer.

Latitudes étant une toute petite structure, elle n’a pas un process Produit avancé avec des objectifs Produit et des frameworks de priorisation. Il y a donc assez peu de moments où la priorisation d’un sujet est directement rattachée à son impact par des éléments chiffrés, et donc assez peu de moments où le poids de l’impact est visible dans la priorisation.

‍

En réalité, c’est plutôt l’absence de contraintes et d’objectifs court-termistes (demandes client, stratégie pour coller aux attentes des investisseurs) qui permet de se donner le temps de faire quelque chose de très adapté aux besoins des utilisateurs et des utilisatrices.

Le “faire bien” me semble plus valorisé ici que dans des structures où on a un peu plus le couteau sous la gorge.

‍

Ce qui se ressent beaucoup plus immédiatement, c’est l’impact des valeurs que l’association défend sur les choix d’outils, ou même sur la manière de faire les choses.

Je suis arrivé avec quelques à priori il faut bien le reconnaître, notamment celui que les valeurs de l’association sur le numérique responsable - même si je m’y retrouve beaucoup à titre personnel - allaient peser lourdement sur ma capacité d’action et sur les choix disponibles en terme d’outils.

Cette contradiction entre mes valeurs personnelles et ma manière de travailler vient je pense de mon habitude du contexte start-up / scale-up où les contraintes et l’éthique numérique sont essentiellement vues comme un poids dans un contexte où le temps est compté !

‍

Une structure comme Latitudes qui s’autorise des compromis entre ses valeurs et un pragmatisme pour augmenter l’impact de son action est dans le juste je pense - d'autant plus avec cette envie de s'affranchir progressivement des outils non alignés avec ses valeurs maintenant que la structure est plus installée.

‍

De la qualité de l’open source

‍

Jusqu’à maintenant j’avais déjà été beaucoup exposé à l’open source et particulièrement convaincu :

• Sur le plan professionnel par les librairies, les distributions et plus généralement tous les outils très techniques permettant de déployer du code ou des apps solides
• Sur le plan personnel par plusieurs outils bureautiques à destination du grand public (Ubuntu, Thunderbird, Firefox pour ne citer qu’eux…)

‍

En revanche j’étais plus circonspect quand aux outils de productivité (notamment cloud), peut être un peu traumatisé par des outils comme Libre office - cal que je trouvais nettement au dessous de la puissance et de l’ergonomie de Google Sheets et Excel.

Là aussi, c’était un a priori qui a été vite effacé.

J’ai découvert des outils incroyablement matures :

• Sur le plan technique : notamment des outils qui s’appuient fortement sur des librairies open source très largement éprouvées pour les rendre plus facile à utiliser avec une interface graphique.Je pense notamment à Supabase, un wrapper PostgreSQL qui exploite l’incroyable potentiel de cette technologie de bases de données pour en faire un mini backend extrêmement facile à utiliser (alors que l’utilisation de PostgreSQL en pures lignes de commandes est un peu plus sèche).
• Sur le plan produit. Contrairement aux stéréotypes, certains outils ont un design et une qualité fonctionnelle exceptionnelles. Par exemple, Metabase (que j’avais utilisé sans être très convaincu il y a quelques années) a développé un onboarding quasi parfait, un système de gestion des droits chirurgical et une ergonomie digne des meilleurs produits sur le marché !

‍

Là encore, ma conclusion n’est pas de me dire que je ne vais plus utiliser que des produits open source, mais qu’en tant que Product Manager il est très légitime de “laisser une chance à ces outils” et de les étudier sérieusement avant de se précipiter sur des outils propriétaires et payants.

‍

Conclusion

‍

Si je devais résumer ce que j’ai appris des mes “surprises” sur les sujets Tech et Produit en arrivant chez Latitudes, c’est que :

• les besoins et les contraintes d’une structure associative peuvent amener à faire les choses mieux que dans des scale-ups. En étant contraint par le budget et guidé par les valeurs, on en vient à explorer des pistes et utiliser des outils plus pertinents que les outils parfois trop “normés” des start-ups et des scale-ups
• à l’inverse, la nature associative d’une structure peut parfois l’éloigner de solutions plus matures, ce qui peut mener à des situations complexes à renverser quand l’association grandit !

‍

Les prochains articles de blog porteront justement sur la mission de “convertir” le SI d’une association en ne gardant que le positif tout en y intégrant ce qu’une technologie plus mature peut apporter.