Aller au contenu
D
Journal
Leadership technique · 12 juillet 2026 · 7 min de lecture

Organiser 8 équipes techniques autour d'un contrat d'interface

Comment un document unique a synchronisé hardware, firmware, backend et mobile sur VisiOne — sans réunion supplémentaire.

Sur VisiOne, huit personnes touchaient au même produit sur des couches très différentes. Une caméra IP ne « fait » rien seule : le hardware envoie un flux, le firmware l’expose, le cloud le relaie, l’application le consomme. Chaque équipe avait tendance à décrire la même chose avec des mots différents — et à l’implémenter avec des schémas différents.

Le problème n’était pas la vitesse

Les gens travaillaient vite. Le problème, c’était l’accord silencieux qui manquait à chaque frontière. « L’état de connexion », par exemple, était réécrit trois fois : le firmware parlait de pairing_ready, le cloud de device_available, l’app Flutter de waiting_camera. La même idée, trois vocabulaires, trois bugs à venir.

Un document, pas un outil

J’ai centralisé la spécification d’interface dans un seul document. Pas un Notion, pas un Confluence, pas un Miro. Un fichier versionné, à côté du code, dont chaque équipe pouvait ouvrir une pull request pour proposer une évolution.

Ce document décrivait :

  • les événements MQTT et leurs payloads exacts ;
  • les états de la caméra, nommés une seule fois ;
  • les codes d’erreur avec leur signification métier ;
  • les responsabilités : qui produit quoi, qui consomme quoi.

L’effet réel

Trois observations, mesurées sur la durée du projet :

  1. Les questions inter-équipes ont chuté. Avant : « comment le firmware nous envoie l’appairage ? » → réponse Slack asynchrone. Après : « c’est dans l’ICD, section 3.2. »
  2. Les bugs de frontière sont devenus visibles avant le code, en revue de PR sur le document.
  3. Les revues techniques hebdomadaires servaient à discuter des décisions, pas à découvrir des divergences.

Ce que je referais différemment

  • versionner le document avec le code dès la première ligne, pas en semaine 3 ;
  • ajouter une section « exemple d’échange complet » par événement — le pseudo-code réel est plus lisible que dix lignes de description ;
  • interdire les décisions d’interface prises verbalement sans PR sur ce document — même si elles paraissent « évidentes ».

Ce n’est pas une méthode nouvelle. C’est la version disciplinée d’un principe ancien : quand une équipe grossit, la coordination coûte plus cher que le code.

DT

Delano Toungsi

Développeur mobile senior Flutter · Yaoundé, Cameroun

Me proposer un entretien →

Un besoin mobile qui vous ressemble ?