Backend
6 développeurs + 1 référentLes services métier, découpés en cinq périmètres indépendants (détaillés ci-dessous). C'est là que se concentrent les règles fonctionnelles et les dépendances entre services.
Le projet en quelques mots
Le sujet demandait de reconstruire les fonctions essentielles d'un réseau social : des comptes, un graphe d'abonnements et de blocages, des publications avec réponses et partages, une recherche, et des fils d'actualité. Le tout en microservices, avec une chaîne de déploiement automatisée.
14
personnes dans l'équipe
3
pôles avec référent technique
3
dépôts de code séparés
~2
mois de développement
Le vrai problème : quatorze personnes en parallèle
Avec une équipe de cette taille, la contrainte dominante n'est plus technique. Si le système est mal découpé, la moitié de l'équipe attend l'autre moitié, et le nombre de développeurs devient un handicap plutôt qu'un avantage.
Mon rôle de chef de projet a donc consisté d'abord à structurer l'équipe en trois pôles autonomes, chacun mené par un référent technique qui arbitre au quotidien sans remonter jusqu'à moi. Les effectifs suivent la charge réelle : le backend, qui porte l'essentiel de la complexité, mobilise plus du double des deux autres réunis.
Frontend
2 développeurs + 1 référentL'interface du réseau social, qui consomme les services backend sans connaître leur découpage interne.
DevOps
2 développeurs + 1 référentLa chaîne de construction et de déploiement, et l'environnement local qui permet aux deux autres pôles de travailler sans se gêner.
À l'intérieur du pôle backend, le système est lui-même découpé en cinq services indépendants, chacun responsable d'un domaine :
Comptes et authentification
Création de compte, connexion, et délivrance du jeton qui identifie l'utilisateur auprès de tous les autres services.
Graphe social
Qui suit qui, et qui bloque qui. Bloquer quelqu'un doit rompre les abonnements existants dans les deux sens.
Publications
Messages, réponses, partages et mentions « j'aime » - avec les règles de cohérence associées.
Recherche
Indexation des publications à leur création, retrait à leur suppression, et interrogation par mots ou par mots-clés.
Fils d'actualité
Le fil personnel d'un utilisateur et celui de ses abonnements, mis à jour en arrière-plan à chaque événement.
Là où le découpage résiste
Découper est facile sur le papier. Ce qui l'est moins, c'est de traiter les endroits où les services doivent se parler - et où une décision prise dans l'un contraint tous les autres. Trois points ont demandé un arbitrage explicite.
- Le blocage traverse tout le système. On ne peut pas partager ni commenter la publication de quelqu'un qui nous a bloqué, ni aimer son contenu. Le service des publications doit donc interroger le graphe social à chaque action - c'est la dépendance la plus structurante.
- Les fils d'actualité ne peuvent pas être calculés à la demande : il faudrait tout parcourir à chaque affichage. Ils sont donc mis à jour en arrière-plan à chaque publication, suppression, mention « j'aime » ou changement d'abonnement - ce qui introduit un décalage assumé entre l'action et son effet visible.
- La recherche a deux sémantiques opposées dans une même requête : les mots ordinaires élargissent le résultat, les mots-clés le restreignent. Un mot précédé d'un dièse ne doit d'ailleurs jamais correspondre au même mot sans dièse - une subtilité facile à manquer et coûteuse à corriger tard.
Outiller pour ne pas se gêner
Un découpage propre ne suffit pas si les développeurs se marchent dessus dans les outils. L'organisation retenue sépare franchement le code applicatif de l'infrastructure : un dépôt pour l'interface, un pour les services, et un troisième qui décrit à lui seul comment tout cela se déploie.
Le principe directeur
Chaque développeur devait pouvoir lancer l'ensemble du système sur sa propre machine, en une commande, sans dépendre de qui que ce soit. C'est ce qui permet de travailler sur un service en ayant les autres sous la main - sans quoi chacun attend un environnement partagé, et l'équipe ralentit.
Le reste de la chaîne découle de là : vérification automatique à chaque modification, fabrication des images applicatives selon la branche, et déploiement piloté depuis le dépôt d'infrastructure. Les remontées de bugs des développeurs alimentaient un flux de tickets traité en continu, en parallèle des sprints.
Synthèse du projet
Travail réalisé
Le pilotage d'une équipe de quatorze personnes sur un réseau social en microservices : structuration en trois pôles avec référents techniques, découpage du backend en cinq périmètres autonomes, arbitrage des dépendances entre services, et mise en place d'une chaîne de déploiement permettant à chacun de travailler sans bloquer les autres.
Ce que le projet m'a apporté
La découverte qu'une grande équipe ne va pas plus vite par elle-même. Le découpage du système détermine la vitesse à laquelle les gens peuvent travailler ensemble : mal posé, il transforme chaque ajout de personne en coordination supplémentaire. C'est une décision d'architecture, mais son effet est d'abord organisationnel.