L’organisation Tech chez Younited Credit

Pour un CTO, DSI, ou responsable d’un domaine IT, le fait de proposer une organisation de son département adaptée au contexte de son entreprise est une préoccupation majeure et permanente.

Dans un contexte où la rapidité d’exécution permet de faire la différence avec la concurrence, les modèles organisationnels traditionnels présentent certaines limites (rigidité, manque de créativité) et nous poussent à en explorer d’autres et à nous forger une vision spécifique répondant aux caractéristiques de notre entreprise.

Cet article décrit l’organisation Tech de Younited Credit mi-2016, en quoi elle répond à ses enjeux et s’aligne sur ses valeurs, ainsi que les points de vigilance qu’elle implique.

Younited Credit, une scale-up en hypercroissance

Younited Credit est une plateforme Internet qui propose un crédit juste, rapide et transparent, grâce à son modèle unique permettant à des investisseurs professionnels de financer directement des crédits à la consommation des ménages (https://www.younited-credit.com/comment-ca-marche).

Sa proposition de valeur, qui la différencie de ses concurrents (sociétés de crédit à distance et agences bancaires) est la rapidité à laquelle le crédit est octroyé, ce qui passe nécessairement par beaucoup d’automatisation des processus et place d’autant plus la Tech au cœur de la stratégie.

L’entreprise compte à ce jour environ 170 personnes (contre une dizaine il y a 5 ans !), dont 130 à Paris, 30 à Rome et 10 à Barcelone.

Les effectifs Tech s’élèvent actuellement à une petite cinquantaine de personnes, parmi lesquelles des développeurs, des Product Owners et des analystes QA.

La croissance de l’entreprise est très forte : depuis son lancement commercial fin 2011, on observe un quasi-doublement de sa production de crédit et de son volume d’affaires chaque année. De plus, depuis 1 an, Younited Credit est présent dans deux nouveaux pays, et nous proposons à présent des crédits à la consommation aux ménages italiens et espagnols.

Nous sommes dans un contexte de déploiement rapide à l’international, tout en optimisant le modèle de rentabilité.

Les valeurs de l’Entreprise

L’entreprise s’est récemment prêtée à l’exercice de la définition de ses valeurs avec ses collaborateurs. 5 valeurs ont émergé :

  • No limit (Ambition) : Être audacieux et ne jamais se fixer de limite.
  • Make it simple (Simplicité) : Simplifier à l’extrême les produits, communiquer de façon claire avec nos clients, être soi-même et accessible entre collaborateurs.
  • Innovate or die ! (Innovation) : Chercher à tout réinventer. Développer des services qui dépassent les attentes et l’imagination de nos clients.
  • Faster is better (Rapidité) : Décider et exécuter toujours plus rapidement.
  • Act as an entrepreneur (Entrepreneuriat) : Oser prendre des initiatives, exprimer ses talents, et respecter le droit à l’erreur !

Les limites des modèles traditionnels

Les modèles traditionnels s’appuient généralement sur une organisation pyramidale fonctionnelle : le travail est divisé en fonctions, ces dernières étant subdivisées en cascade en les spécialisant.

Chaque subdivision est pilotée par un manager.

La transversalité

Cette organisation est très efficace pour améliorer l’efficacité et l’expertise nécessaire dans chaque fonction, mais elle présente une difficulté majeure pour la création de valeur finale pour l’entreprise (concrètement, des €). En effet, c’est la combinaison de ces fonctions qui permet de produire cette valeur, or la pyramide avec ses nombreux niveaux et ses « nœuds » que sont les managers constituent un réel obstacle à la collaboration de ces fonctions : objectifs divergents, plans de charge mal synchronisés, circulation de l’information difficile. Dans les entreprises qui ont adopté un tel modèle organisationnel, on demande aux collaborateurs toujours plus de « transversalité » pour réaliser les projets et les tâches du quotidien, ce qui est complexe et peu efficace, car toute l’organisation va à l’encontre de cette collaboration !

Le rôle du manager

Le manager dans les organisations traditionnelles a plusieurs responsabilités : animer son équipe au quotidien (répartir les tâches entre les collaborateurs, faire circuler l’information, organiser les points de rencontre), prendre les décisions pour mener à bien l’activité de l’équipe, apporter l’expertise nécessaire au bon déroulement des travaux, définir et évaluer les objectifs des membres de l’équipe, mettre en place les actions permettant le développement de ses collaborateurs, etc.

Ses tâches sont légitimes et importantes dans une organisation, mais le fait qu’elles soient cumulées par une même personne pose quelques problèmes :

  • Il est à la fois juge et partie dans l’évaluation des collaborateurs : sa performance personnelle dépend de celle de ses équipes. C’est lui qui doit leur donner les moyens d’atteindre les objectifs qu’il leur a fixés, et c’est toujours lui qui les évalue. Il peut être difficile de rester objectif dans ces conditions.
  • Il doit être à la fois leader (susciter l’adhésion à un projet d’équipe et accompagner ses membres) et expert (référent dans le domaine technique de l’équipe), et s’il n’est qu’un seul des deux, il peut y avoir un problème de légitimité.
  • Il est tiraillé entre des attentes souvent contradictoires entre sa propre hiérarchie (performance, rendement) et son équipe (moyens, conditions de travail).
  • Il perd progressivement son expertise en passant la majorité de son temps à des tâches administratives, peu productives.

L’autonomie

Dans les organisations classiques, relativement peu d’autonomie est laissée aux collaborateurs. Et même si un manager ouvert et bienveillant favorise la prise d’initiative, il peut être très vite décourageant de mettre en œuvre des idées d’amélioration dont le périmètre d’exécution dépasse celui de l’équipe, car on se heurte alors aux managers concernés, qui n’ont peut-être pas les mêmes intérêts. Dans ce contexte, on imagine facilement comment les collaborateurs les plus moteurs se résignent ou quittent l’entreprise.

L’organisation Tech chez Younited Credit

Nous avons estimé que les modèles d’organisation traditionnels n’étaient pas adaptés à notre contexte, et que leurs inconvénients étaient particulièrement antinomiques avec nos valeurs.

Nous avons donc étudié d’autres approches et nous sommes inspirés, entre autres, des fameuses « feature teams » mises en place chez Spotify (http://www.frenchweb.fr/comment-spotify-revolutionne-le-management-avec-plus-dautonomie/234578), de quelques principes en vigueur en Holacratie (https://fr.wikipedia.org/wiki/Holacratie), et les avons complétés, puis adaptés, convaincus qu’il n’y a pas de solution toute faite, chaque contexte étant particulier et nécessitant une solution spécifique.

Une de nos particularités est l’hypercroissance, il faut donc concevoir un modèle organisationnel extrêmement scalable, c’est-à-dire suffisamment souple pour accueillir rapidement un grand nombre de nouveaux collaborateurs et s’adapter aux changements de contexte, tout en ne nécessitant pas d’être repensé entièrement à chaque fois.

L’organisation mise en place chez Younited Credit peut difficilement se représenter sur un seul schéma, car elle résulte de la combinaison de plusieurs axes.

L’axe hiérarchique (#MakeItSimple)

Pour les raisons évoquées précédemment, nous ne souhaitons pas fonder l’organisation sur des liens hiérarchiques entre les personnes. L’organisation d’un point de vue hiérarchique est donc très plate : chaque personne est directement rattachée au CTO.

L’absence de structure hiérarchique nous permet à la fois d’être très souple et de permettre une grande simplicité dans les relations humaines et la communication entre les personnes : tout le monde est accessible, il n’y a pas de liens de subordination.

L’axe hiérarchique n’a que peu d’importance dans notre organisation : ce n’est pas sur ce dernier que nous nous appuyons pour créer de la valeur pour l’entreprise, mais sur l’axe opérationnel.

L’axe opérationnel

Nous appelons l’axe opérationnel celui qui définit les rôles, leurs responsabilités et les interactions entre les personnes pour délivrer de la valeur pour l’entreprise.

Produire de la valeur

Par opposition aux modèles en pyramide fonctionnelle, nous avons choisi comme axe majeur d’organisation celui de la capacité à produire de la valeur finale pour l’entreprise (bien souvent, des Euros qui apparaissent de façon significative dans le Compte de Résultat de l’entreprise), et non pas celui de la fonction ou de la compétence. Et comme vu plus haut, cette valeur est produite grâce à la combinaison de différentes fonctions. De plus, nous sommes convaincus que c’est en travaillant à effectifs réduits que nous sommes les plus efficaces (il n’y avait encore que 10 personnes en 2012 dans l’entreprise).

Nous avons donc opté pour une organisation fondée sur des petites équipes pluridisciplinaires et axées sur les métiers de l’entreprise, les « Younits ».

Les « Younits » (#ActAsAnEntrepreneur)

Les « Younits » regroupent donc des compétences issues des différents départements, métiers et Tech, en faisant abstraction totale du rattachement initial (hiérarchique) de chacun des membres de l’équipe pour composer ces unités de travail capables de produire de la valeur en toute autonomie.

Chaque Younit définit ses propres objectifs concourant à la stratégie globale de l’entreprise, et est libre de déterminer les réalisations permettant de les atteindre.

Les membres d’une Younit, qu’ils soient issus des département métier ou de la Tech, sont colocalisés : ils se regroupent dans des zones des openspaces, qu’ils organisent comme ils le souhaitent.

Chaque équipe est garante d’un périmètre applicatif, qui représente un levier pour le métier qu’elle représente (ex : le formulaire d’acquisition pour la younit webmarketing, le CRM d’octroi de crédits pour les opérationnels analystes de crédit).

Ces équipes sont donc focalisées sur la création de valeur en délivrant en continu des évolutions sur leur périmètre applicatif (A/B tests pour éprouver de nouveaux principes ergonomiques, optimisations et automatisations diverses).

Et comment gère-t-on les projets ? (#InnovateOrDie)

Dans certains cas, il est nécessaire d’apporter un investissement initial conséquent avant de pouvoir tirer de la valeur business : le démarrage d’une activité dans un nouveau pays (qui nécessite des adaptations du SI dans la majorité de ses composantes), la refonte d’une application métier en vigueur depuis plusieurs années et dont une régression du périmètre fonctionnel serait synonyme de perte de business, etc.

Nous avons par le passé essayé de traiter ce type de travaux au sein de ces équipes produit (l’ancien nom des younits), convaincus que ces projets pouvaient être suffisamment découpés, priorisés et intégrés à la roadmap des applications de l’équipe, mais nous nous sommes heurtés à de gros problèmes. Dans certains cas, nous avons donné la priorité aux petites évolutions, séduits par leur ROI avantageux et immédiat, et avons eu beaucoup de mal à garder le focus sur les travaux qui relèvent d’un projet, ce qui a étiré en longueur leur réalisation et a sensiblement décalé dans le temps leurs bénéfices. Dans d’autres, nous nous sommes concentrés sur un gros projet (le démarrage d’une activité commerciale en Italie), mais avons pendant environ 4 mois perdu toute agilité, nous n’étions pas capables de répondre rapidement à des besoins simples de nos métiers.

Nous avons finalement décidé de créer des younits dédiées aux projets. Elles sont constituées pour les besoins d’un projet spécifique, et existent le temps de ce projet.

Cela pose un nouveau problème, car ces younits projet ont parfois besoin d’apporter des évolutions à des applications qui sont sous la responsabilité d’autres younits.

Comment rompre la dépendance entre les équipes et décorréler les roadmaps ?

Afin de découpler les roadmaps des différentes équipes, nous avons décidé de permettre aux équipes d’apporter des évolutions à des applications qui ne sont pas sous leur responsabilité. De cette manière, pas besoin d’essayer d’inscrire de nouvelles features dans le backlog d’une autre équipe qui n’a pas les mêmes objectifs, ce qui peut être problématique.

Si tout le monde peut toucher à tout, comment garantir la qualité des applications ?

Lorsqu’une équipe doit apporter des modifications à une application dont elle n’a pas la responsabilité, elle doit dans un premier temps consulter l’équipe qui en a la charge pour lui exposer son besoin et prendre en compte les recommandations techniques et fonctionnelles émises par cette dernière. Dans un second temps, l’équipe qui réalise les modifications doit soumettre son code à la validation de l’équipe responsable de l’application, qui vérifiera le respect des guidelines de programmation sur son composant. De cette manière, on évite les dérives dues à des développeurs qui font évoluer successivement et sans concertation une application, qui perd progressivement toute cohérence et qui accumule de la dette technique.

Les rôles

L’absence de hiérarchie pyramidale n’implique pas l’absence de responsabilités, elles sont simplement beaucoup plus distribuées, et cette nouvelle organisation oblige d’ailleurs à mieux les définir et mieux les partager. Les responsabilités sont portées par les rôles, qui sont bien distincts des personnes : une personne peut endosser plusieurs rôles, et un rôle peut être tenu par plusieurs personnes.

Chaque rôle est décrit simplement sur une feuille A4, à disposition de tous, sur laquelle apparaît la finalité du rôle, le périmètre d’action et ses responsabilités. Ils doivent être décrits suffisamment clairement pour éviter toute ambiguïté au quotidien, et cependant avec suffisamment de souplesse pour ne pas devoir mettre à jour le document à la moindre évolution, ce qui serait difficile à maintenir.

Certains rôles ont des responsabilités plus grandes que d’autres, mais il n’y a pas de relation de subordination entre les rôles. Les deux premiers rôles sont joués par des personnes du métier, les quatre suivants par des collaborateurs de la Tech :

Business Owner : C’est le garant de la stratégie métier. Il décide de la priorisation du Backlog en fonction des enjeux business et de la complexité.

Business StakeHolder : Experts sur un aspect spécifique du métier traité par l’équipe.

Application Manager : Il analyse le besoin métier pour concevoir, avec l’aide du reste de l’équipe, la solution à mettre en œuvre. Il est en charge du pilotage des réalisations et anime la vie de l’équipe. Le tandem qu’il forme avec le Business Owner est clé pour la réussite de l’équipe.

Lead Développeur : Il anime l’équipe sur un axe technique, et est responsable de la qualité des applications sur son périmètre. Il est l’interlocuteur privilégié des autres équipes pour tout besoin de synchronisation ou de support.

Développeur : Il contribue à l’analyse des besoins métier et réalise et gère la solution de bout en bout (amène ses évolutions jusqu’en production)

Ingénieur QA : Garant du processus global qualité de l’équipe. Il bâtit la stratégie de tests, exécute les tests et les automatise.

La méthodologie (#FasterIsBetter)

Les younits respectent toutes comme principes de base le développement itératif et incrémental. Selon leur contexte propre, cela peut prendre la forme de pratiques proches de Scrum ou de Kanban. La finalité est la même : délivrer la valeur business la plus forte dans le temps le plus court.

La prise de décision

Certains rôles ont la responsabilité de prendre des décisions sur leur domaine d’expertise. La prise de décision ne doit pas être unilatérale, elle relève davantage d’une animation autour d’une problématique pour faire aboutir une décision collégiale dans le bon timing et en connaissance de cause, c’est-à-dire en ayant su réunir les bonnes personnes, au bon moment et en leur ayant donné les informations pertinentes.

L’organisation technique

L’axe principal de l’organisation qui a été choisi est celui de la production de valeur finale pour l’entreprise, c’est-à-dire l’axe des métiers. Il ne faut pas pour autant négliger l’axe technique, sinon les équipes vont bâtir des solutions n’ayant aucune homogénéité entre elles, et c’est alors s’exposer au risque d’augmenter considérablement la complexité du SI (incohérences, grande diversité des solutions, etc.), de perdre du temps à réinventer des solutions déjà mises en place et de devoir s’approprier un nouveau contexte à chaque changement d’équipe.

Pour cela, une younit technique a été créée, regroupant des spécialistes aux compétences complémentaires, avec une action transverse aux autres younits : architecture technique, architecture logicielle, DevOps, sécurité, etc. La mission de cette équipe de spécialistes est d’aider les younits à partager leurs bonnes pratiques, leur permettre d’utiliser et de s’approprier des outils leur permettant d’améliorer la qualité et leur productivité.

Chaque spécialiste anime une communauté technique (une younIT) spécifique avec un représentant dans chaque younit. La younit technique a son propre backlog pour avancer de façon coordonnée sur les différents sujets techniques transverses.

La gouvernance

Les younits sont assez libres d’organiser la vie de leur équipe comme elles le souhaitent, néanmoins, afin de faciliter la gouvernance globale, certains « points de rencontre » et leur reporting associé sont obligatoires et homogènes :

Le daily meeting : C’est le stand-up meeting classique de Scrum, toute l’équipe est présente et se retrouve devant son « board » pour partager les avancements et difficultés de la veille et l’objectif du jour.

Le meeting bimensuel : quelle que soit la méthodologie adoptée par l’équipe, qu’elle soit plus inspirée de Scrum ou de Kanban, des itérations de 2 semaines sont définies pour faire le point sur ce qui a été mis en production, planifier les travaux à venir et maintenir une dynamique d’amélioration continue. Un reporting avec un template qui est le même pour tous est diffusé à toutes les personnes intéressées.

Le comité roadmap : c’est une réunion mensuelle, à laquelle participent quelques membres du Comité Exécutif (ComEx), dont bien sûr le directeur général de l’entreprise et le CTO, et qui a pour but de communiquer la valeur business qui a été produite dans le mois écoulé (revenus générés, économies réalisées, etc.), ainsi que la valeur prévisionnelle pour le mois à venir. Les problèmes qui ne peuvent pas être réglés par l’équipe seule sont évoqués pour que le ComEx travaille à des solutions. Enfin, en fonction des résultats obtenus et des problèmes rencontrés, le ComEx peut décider de réallouer des efforts (concrètement, des développeurs) entre les équipes. Un format unique de reporting est lui aussi utilisé, afin d’en faciliter la rédaction et la comparaison entre les younits.

Les « younIT meetings » : il s’agit des réunions organisées par les responsables techniques transverses avec leur communauté composée de membres appartenant aux différentes younits. C’est l’occasion de suivre l’avancement des actions, d’identifier de nouveaux problèmes à résoudre et de partager de bonnes pratiques. Il y a en moyenne 1 réunion par mois et par communauté.

La réunion d’équipe : c’est une réunion hebdomadaire qui rassemble l’ensemble de l’équipe Tech (env. 50 personnes actuellement), et lors de laquelle nous partageons les informations clés de la semaine écoulée, et une ou deux démonstrations de travaux accomplis par une équipe, cela dans une ambiance assez conviviale (la rubrique « citations de la semaine » est souvent assez croustillante).

La recherche permanente d’efficacité en tentant d’améliorer en continu les interactions entre les collaborateurs, la répartition des responsabilités, la circulation de l’information est essentielle, mais il ne faut pas oublier que tout cela repose sur les collaborateurs. L’entreprise doit les considérer en tant qu’individus, ce qui doit apparaître dans l’organisation.

L’axe humain

Il s’agit ici de veiller au bien-être du collaborateur, d’être à l’écoute de la façon dont il vit l’aventure d’entreprise et de son projet personnel au sein de cette dernière.

L’approche que nous avons choisie est de faire en sorte que chaque membre de la Tech ait un référent, un coach qui soit en charge de cette mission.

L’organisation hiérarchique étant très plate, il n’était pas viable de confier au responsable hiérarchiques la responsabilité de coaching, cela aurait représenté pour un même coach beaucoup trop de collaborateurs à accompagner.

L’organisation opérationnelle étant très adaptative, il ne nous a pas semblé opportun d’y associer le rôle de coach, la relation entre un « parrain » et un « filleul » devant se construire sur le long terme.

Nous avons donc créé un 3ème axe à notre organisation, centré sur l’humain, et créé un nouveau rôle : le « Youman ».

Ce Youman a donc les responsabilités suivantes vis-à-vis de ses filleuls :

  • Veiller à son bien-être au quotidien : faire avec lui des points réguliers pour s’assurer qu’il vient au travail avec le sourire, défendre ses intérêts.
  • Faciliter son parcours dans l’entreprise : recueillir ses souhaits d’évolution, l’aider à mettre en œuvre les moyens nécessaires et suivre la bonne exécution du plan. Les Youmen sont efficacement aidés dans cette démarche par le département RH, qui fait des entretiens de carrière réguliers.
  • Aider le collaborateur à attendre ses objectifs : s’assurer, entre autres, que les moyens pour y parvenir son bien présents.

Les points de vigilance

Cette organisation répond à nos enjeux actuels et apporte des solutions à bon nombre de nos problèmes, mais, comme aucune solution n’est parfaite, elle en crée aussi de nouveaux.

Dissémination des équipes Tech

Les membres de l’équipe Tech étant répartis au sein des différents métiers, tant au niveau organisationnel que géographique, la communication entre eux est plus difficile, moins naturelle, et le partage d’information doit être davantage provoqué, organisé (cf. animation technique transverse, réunion d’équipe, etc.). Les développeurs comprennent beaucoup mieux le métier pour lequel ils travaillent, mais ont parfois plus de mal à savoir ce que font leurs homologues dans d’autres équipes.

Changements de mission fréquents

L’adaptabilité aux changements de contexte est un enjeu majeur de cette organisation, et elle y répond bien, néanmoins, cela conduit concrètement à ce que certains collaborateurs doivent changer d’équipe, et donc de contexte de travail, soit de façon soudaine, soit de façon fréquente. On a beau avoir un état d’esprit « Agile » et « accueillir le changement favorablement », c’est un effort pour tout humain de devoir s’adapter à un changement.

Conclusion

Nous avons mis en place cette organisation au 1er septembre 2016. Auparavant, la Tech était déjà organisée en lignes de métiers, mais nous n’avions pas fait le pas de casser les barrières entre les départements, ni de donner autant d’autonomie aux équipes.

Il a fallu deux bons mois de rodage avant que nous ne commencions à tirer les bénéfices que nous en attendions. Nous estimons aujourd’hui que cette organisation est efficace dans notre contexte actuel, et présente les avantages d’être très flexible, d’être scalable, de stimuler la production de valeur pour l’entreprise, ces enjeux étant vitaux lorsqu’on est en hypercroissance.

Les younits sont devenues au fil du temps de réels centres de profits, présentant chaque mois au ComEx les revenus supplémentaires générés par rapport au mois précédent, et défendant, chiffres à l’appui, les moyens complémentaires nécessaires pour améliorer encore leur performance.

En somme, nous avons créé des startups dans la startup, finalement, quoi de plus naturel pour une scale up (#NoLimit) !!!