Deux équipes, une incompréhension structurelle

Chez DJUST, les APIs ne sont pas consommées uniquement par des clients externes. L'équipe FOC — Front of Customers, les développeurs qui construisent et maintiennent notre SDK Front — est le premier consommateur interne de nos APIs Backend.

Pendant longtemps, cette relation fonctionnait "à peu près". Le Back développait des endpoints, le FOC les intégrait dans le SDK, les clients finaux utilisaient le SDK. En théorie, une chaîne simple. En pratique, une source de friction permanente.

Les symptômes sont apparus progressivement dans les rétros :

> "Monter un point pour les problèmes d'évolutions qui impactent le FOC sans prévenir"

> "Trouver un point d'entrée front pour communiquer avec les intégrateurs front"

Ces actions revenaient d'une rétro à l'autre, trimestre après trimestre, sans vraiment être résolues. C'est le signe classique d'un problème structurel qu'on panse sans jamais traiter la cause.

Les frustrations des deux côtés

La réunion de clarification a eu lieu en octobre 2025. Ce qu'on a mis à plat :

Du côté Back :

  • Le FOC implémente parfois des choses "à leur manière" sans consulter le Back au préalable

  • Des décisions d'architecture Front impactent le comportement attendu des APIs Backend sans qu'on soit au courant

  • On découvre après coup que le SDK fait des appels qu'on n'avait pas anticipés

Du côté FOC :

  • Le Back change des contrats API sans prévenir — et le SDK se retrouve cassé du jour au lendemain

  • On n'est pas consulté lors de la conception des nouvelles features qui vont toucher le SDK

  • On est le premier à découvrir les bugs et incohérences des APIs, mais on n'a pas de canal clair pour les remonter

Le constat rédigé à chaud après la réunion :

> "Frustrations des 2 côtés. Les deux équipes se reprochent de 'faire des choses sans en parler aux autres' et de ne pas s'écouter."

Ce n'est pas une question de mauvaise volonté. C'est une question de structure : sans framework clair, chaque équipe optimize localement au détriment du global.

La vision qu'on a construite ensemble

Le vrai travail de la réunion n'était pas de lister les frustrations — c'était de formuler une vision partagée. Ce qu'on a posé :

Le FOC est un partenaire privilégié du Back, qui a la charge de développer un SDK utilisé par l'ensemble des partenaires. Le SDK est une extension du produit DJUST, générique, qui doit évoluer au même rythme que son produit.

Cette phrase semble simple, mais elle change beaucoup de choses. Elle dit que :

  1. Le SDK n'est pas un projet parallèle — c'est une extension du produit. Sa qualité est la qualité du produit.

  2. Le FOC n'est pas un client lambda — c'est un partenaire privilégié avec des droits ET des responsabilités spécifiques.

  3. "Évoluer au même rythme" — le SDK ne peut pas être en retard d'une release sur le Back. Ce n'est pas acceptable.

Les trois casquettes du FOC

On a ensuite décliné cette vision en trois rôles distincts, qui coexistent :

En tant que partenaire standard

Le FOC utilise nos APIs comme n'importe quel intégrateur externe. Il doit :

  • Utiliser la documentation (README, Swagger) comme référence

  • Être autonome sur les APIs publiques disponibles

  • Ne pas avoir accès à des "raccourcis" non documentés

C'est important. Si le FOC a besoin de raccourcis pour implémenter le SDK, c'est que notre documentation est insuffisante pour les partenaires externes. Le FOC est notre premier signal qualité.

En tant que partenaire privilégié

Parce qu'il est le premier consommateur de nos nouvelles APIs, le FOC a des responsabilités supplémentaires :

  • Remonter immédiatement tout problème rencontré en phase de lancement (manque de doc, bugs, comportements inattendus)

  • Être consulté sur la définition des standards API — il a une expérience unique d'avoir implémenté des dizaines de FOC clients

  • Participer à la conception des futures fonctionnalités qui toucheront les contrats API

En tant que responsable du SDK

C'est le rôle le plus contraignant : le FOC doit être au courant en amont des évolutions roadmap pour pouvoir planifier l'implémentation SDK en parallèle du développement Back. Pas après. Pas le jour de la release. En amont.

Les actions concrètes

La vision, c'est bien. Les actions, c'est mieux. Ce qu'on a décidé :

1. Finaliser les standards API avec le FOC
Des APIs simples, cohérentes et bien documentées réduisent naturellement les frictions. On ne peut pas demander au FOC d'être autonome si nos APIs sont ésotériques. Responsable : le Tech Lead.

2. Un référent FOC dédié par feature
Pour chaque feature qui touche les APIs, un référent FOC est désigné par le Head of FOC. Ce référent :

  • Est consulté sur les choix API dès la conception

  • Participe au Kick-Off Feature

  • Communique au Back comment il va implémenter la partie SDK

  • Met à jour le SDK en parallèle du développement Back

3. Anticipation des évolutions tech
On a listé des cas concrets d'évolutions tech qui avaient impacté le FOC sans prévenance :

  • Le passage au nouveau DAM — le FOC a découvert les changements lors de la mise en production

  • Le monitoring SSR — une décision d'architecture qui avait des implications FOC que personne n'avait anticipées

Le principe : toute évolution technique qui touche le comportement de nos APIs doit être présentée au FOC avant d'être développée.

Ce que ça change concrètement

Six mois après cette réunion, voici ce qu'on observe :

Ce qui marche mieux :

  • Le projet Carte Achat de Niveau 3 a été le premier test du nouveau process. Un message formel a été envoyé à l'équipe FOC en amont pour les informer de l'impact API et leur demander des retours préliminaires. Le Head of FOC a confirmé l'importance de la démarche immédiatement.

  • Les breaking changes sont maintenant communiqués en amont via nos release notes. Le FOC sait quoi préparer avant la release du jeudi.

Ce qui reste difficile :

  • La discipline sur les kick-offs feature. Quand on est dans le rush d'un sprint, la tentation de "finir d'abord, aligner ensuite" est forte.

  • Le SDK a tendance à prendre du retard sur le Back malgré les bonnes intentions. La roadmap commune reste un chantier.

Ce qu'on a appris :
Une réunion ne résout pas un problème structurel. Elle pose les bases. Le vrai travail, c'est de tenir les engagements dans la durée — et d'ajuster quand ça glisse.

Pour les Engineering Managers

Si vous gérez une équipe Backend dont les APIs sont consommées par un partenaire interne (SDK, intégrateur, équipe Front), voici ce que j'ai appris :

Ne présumez pas que "ils savent ce qu'on fait". La transparence par défaut n'existe pas entre équipes. Il faut des rituels explicites.

Distinguez les rôles. Un partenaire interne n'est pas un client externe et n'est pas non plus un membre de votre équipe. C'est une catégorie à part, avec ses droits et ses responsabilités propres.

Le SDK est votre premier signal qualité. Si votre partenaire interne a besoin de workarounds pour implémenter son SDK, c'est que vos APIs ont un problème. Écoutez-le.

La vision commune précède les process. On a essayé de résoudre les frustrations avec des actions concrètes pendant des mois, sans succès. Quand on a posé la vision en premier (le FOC est un partenaire privilégié, le SDK est une extension du produit), les actions ont suivi naturellement.

Chetana YIN — Novembre 2025
Engineering Manager chez DJUST. OMS, Payments, Cart.