Quand une équipe nearshore déçoit, le diagnostic tombe vite : la distance, la culture, le niveau, le décalage horaire. Ce sont des explications confortables. Elles placent le problème de l'autre côté de la Méditerranée.

Dans la plupart des cas que nous voyons, le problème est ailleurs. Il est dans une question que personne n'a posée au démarrage : qui décide de quoi ?

Une équipe à Casablanca ou à Rabat qui doit attendre Paris pour chaque arbitrage n'est pas une équipe. C'est une file d'attente. Et une file d'attente, même composée d'excellents ingénieurs, produit lentement, apprend peu et finit par partir.

Le symptôme : tout remonte

On reconnaît une équipe sans droits de décision à quelques signes simples.

  • Les questions s'accumulent dans un canal de discussion et attendent la réunion du lendemain.
  • Le responsable sur place relaie les demandes mais ne tranche rien.
  • Les priorités changent sans que l'équipe sache pourquoi.
  • Les meilleurs profils posent de moins en moins de questions, puis cherchent ailleurs.

Le dernier point est le plus coûteux. Un ingénieur senior accepte une rémunération, un projet, un employeur. Il n'accepte pas longtemps de ne servir à rien dans les choix qui le concernent. Nous l'avons écrit à propos de la rétention : garder son équipe est le vrai risque du nearshore. L'absence d'autonomie en est l'une des premières causes.

La cause : on a délocalisé l'exécution, pas la responsabilité

Le schéma est presque toujours le même. L'entreprise française a défini un périmètre, recruté une équipe, installé les outils. Elle a transféré du travail. Elle n'a pas transféré de pouvoir de décision.

Ce n'est pas de la mauvaise volonté. C'est un réflexe de prudence : on ne connaît pas encore l'équipe, on garde la main. Le problème, c'est que ce réflexe dure. Six mois plus tard, l'équipe a fait ses preuves, mais l'organisation n'a pas bougé. Les décisions continuent de remonter par habitude.

Résultat : le manager côté France devient le goulot d'étranglement. Il passe ses journées à répondre à des questions qu'il n'aurait jamais dû recevoir. Et il en conclut, à tort, que l'équipe manque d'autonomie.

La méthode : écrire les droits de décision

La solution n'est pas un séminaire sur la confiance. C'est un document d'une page, rédigé avant le démarrage et revu chaque trimestre. Il répond à une question pour chaque type de décision : qui décide, qui est consulté, qui est simplement informé.

1. Lister les décisions récurrentes

Pas les grandes orientations. Les décisions de tous les jours :

  • choisir une solution technique dans un cadre donné ;
  • réorganiser les tâches de la semaine ;
  • accepter ou refuser une demande d'un utilisateur interne ;
  • recruter, évaluer, augmenter ;
  • livrer en production ;
  • engager une petite dépense (outil, formation).

Une vingtaine de lignes suffit. L'exercice prend une heure. Il évite des mois de malentendus.

2. Placer chaque décision au bon endroit

La règle que nous appliquons est simple : une décision se prend au plus près de l'information nécessaire pour la prendre.

Le choix d'une bibliothèque logicielle appartient à ceux qui l'utilisent. L'arbitrage entre deux clients appartient à ceux qui connaissent les clients. Le recrutement d'un développeur à Rabat appartient au responsable de Rabat, avec un avis de Paris, pas l'inverse.

Pour chaque ligne, une seule personne décide. Si deux personnes décident, personne ne décide.

3. Donner un vrai responsable sur place

Un « coordinateur » qui transmet les demandes ne suffit pas. Il faut sur place une personne qui a autorité sur l'organisation du travail, le recrutement et le quotidien de l'équipe. Elle rend des comptes à Paris sur des résultats, pas sur chaque choix.

C'est souvent le recrutement le plus important de tout le projet. Il mérite plus de temps que les autres, et il doit être fait en premier.

4. Définir ce qui remonte, et seulement ça

Certaines décisions doivent rester au siège : le budget global, les priorités produit, les engagements contractuels avec les clients. Le document le dit clairement. Tout ce qui n'y figure pas se décide localement.

Cette liste courte protège les deux côtés. Paris garde la main sur l'essentiel. L'équipe sait exactement où s'arrête son autonomie, et peut avancer sans demander.

5. Élargir le périmètre à date fixe

Le document n'est pas figé. Chaque trimestre, on regarde ce qui a fonctionné et on déplace une ou deux décisions vers l'équipe. C'est un mécanisme simple de progression, et un signal fort pour les personnes : la confiance se gagne, et elle se traduit concrètement.

Ce que ça change pour le manager côté France

Son rôle change de nature. Il ne répond plus aux questions. Il fixe le cap, explique le contexte et vérifie les résultats.

Trois rituels suffisent la plupart du temps :

  • une revue hebdomadaire courte sur les résultats, les blocages et les décisions prises localement ;
  • une revue mensuelle avec le responsable sur place sur l'équipe, les recrutements et le périmètre ;
  • une présence physique régulière, au Maroc, pas seulement en visioconférence. Le décalage est faible et le trajet court : c'est précisément l'avantage du nearshore. Il serait dommage de ne pas s'en servir.

Le reste du temps, l'équipe travaille. C'est le but.

Ce que nous avons vu fonctionner

Chez Ippon, l'équipe au Maroc a été montée en moins de six mois. Pour Financia à Rabat, il a fallu neuf mois. Dans les deux cas, la vitesse de recrutement a compté. Mais ce qui a fait tenir les équipes ensuite, c'est d'avoir donné tôt à des responsables locaux un vrai pouvoir sur leur périmètre.

Une équipe nearshore n'est pas une extension du bureau de Paris. C'est une équipe à part entière, avec ses responsables, ses décisions et ses résultats. Les entreprises qui la traitent ainsi obtiennent ce qu'elles venaient chercher. Les autres obtiennent une file d'attente.

---

Vous montez une équipe au Maroc, ou celle que vous avez remonte tout à Paris ? Écrivez-nous : on regarde avec vous comment répartir les décisions.