16 September 20257 min de lecture
Personne ne budgète la montée en charge. Le contrat démarre le premier du mois, le tarif est convenu, et l’hypothèse sous-jacente au plan est que le travail utile commence ce matin-là. Ce n’est pas le cas, et l’écart entre cette hypothèse et la réalité est l’endroit où part une part surprenante de l’argent.
Ce n’est pas un reproche à l’externalisation. Un nouveau salarié a la même montée en charge, et généralement plus longue. La différence, c’est que personne n’attend d’un salarié qu’il soit productif la première semaine, et que tout le monde l’attend de quelqu’un que l’on paie à la journée. Cette attente rend les deux premières semaines pires, pas meilleures.
La montée en charge est réelle, et elle n’est pas gratuite
Quelqu’un qui arrive sur une base de code inconnue doit apprendre trois choses distinctes : comment fonctionne le système, comment fonctionne votre équipe, et ce que vous voulez réellement. La première est la plus rapide, car elle est écrite dans le code. Les deux autres ne sont presque jamais écrites nulle part, et c’est ce qui rend l’intégration à distance plus difficile que sa version en présentiel.
Dans un bureau, la troisième catégorie fuit d’elle-même. Vous entendez la discussion sur le processus de mise en production, vous remarquez que la personne attachée à la couverture de tests est assise deux bureaux plus loin, vous apprenez que personne ne touche au service de facturation sans demander d’abord. Rien de tout cela n’atteint quelqu’un qui travaille depuis Beyrouth, à moins de le déposer quelque part délibérément.
Prévoyez-la. Une hypothèse de travail raisonnable pour un ingénieur de niveau intermédiaire arrivant sur un système de complexité ordinaire : une première semaine qui produit peu, une deuxième semaine qui produit quelque chose de petit et de réel, et un premier mois qui s’achève sur des livraisons sans supervision pour les travaux bien compris. Si vous n’avez pas laissé de place à cela, le plan est faux et la personne en paiera le prix.
Semaine zéro : ce qui doit exister avant leur arrivée
L’action au meilleur rendement consiste à déplacer les blocages ennuyeux avant la date de démarrage plutôt qu’après. Chaque heure passée à attendre un compte est facturée au même tarif qu’une heure passée à écrire du code.
- Chaque compte créé et testé par quelqu’un d’autre : dépôt, CI, outil de suivi des tickets, messagerie, préproduction, suivi des erreurs, et tout ce que le travail touche par ailleurs.
- Un README qui permet de lancer le projet en local, vérifié le mois dernier par quelqu’un qui l’a suivi à la lettre plutôt que de mémoire.
- Une personne désignée chargée de répondre à leurs questions, cette responsabilité étant énoncée à voix haute plutôt que supposée.
- Un premier ticket, choisi à l’avance, petit et réellement utile.
- Les documents signés : le contrat, la cession de propriété intellectuelle, et l’accord de traitement des données s’ils toucheront à quoi que ce soit de personnel.
Rien de tout cela n’est difficile. C’est simplement un travail qui n’est fait que si quelqu’un en est responsable, et il n’a presque jamais de responsable, ce qui explique que la première semaine disparaisse si souvent en demandes d’accès.
La première tâche doit être petite, réelle et livrable
L’instinct est de commencer par la lecture : voici la base de code, passez quelques jours à vous familiariser. C’est un mauvais usage d’une semaine. Lire un système sans raison d’y toucher produit une carte superficielle qui s’évapore dès le lundi suivant.
Confiez-leur plutôt quelque chose de petit qui part en production. Une correction de bug visible, un petit point d’API, un texte qui doit traverser toute la chaîne. L’intérêt n’est pas le changement. L’intérêt est que le livrer les oblige à traverser d’un coup chaque étape de votre processus : installation locale, conventions de branches, revue, CI, déploiement, et la personne qui doit approuver. Ils trouveront les parties cassées de votre processus, parce qu’ils sont les seuls dans la maison à ne pas avoir déjà appris à les contourner.
Le contexte arrive par couches, pas dans un document unique
On est tenté de rédiger l’énorme document d’intégration. Il survit rarement au contact de la réalité, car il est écrit une fois, lu une fois, et périmé en un trimestre.
Un schéma plus durable est en couches. Une courte page d’orientation qui explique ce que fait le produit, qui l’utilise et comment l’argent arrive à l’entreprise. Une deuxième couche de notes d’architecture, idéalement placées à côté du code qu’elles décrivent. Une troisième couche qui n’est pas un document du tout : l’habitude de consigner le raisonnement dans les tickets et les pull requests, pour que le contexte arrive attaché au travail plutôt que dans un dossier que personne n’ouvre deux fois.
C’est la troisième couche qui compte sur un an. Les deux premières font passer la première quinzaine.
Désignez une personne, pas une équipe
« Demandez sur le canal si vous bloquez » sonne accueillant et fonctionne comme un mur. Une nouvelle recrue n’ira pas interrompre huit inconnus pour poser une question qu’elle soupçonne d’être évidente : elle passera plutôt deux heures à deviner, et la supposition sera fausse d’une manière qui coûtera une journée en revue.
Désignez une personne comme premier point de contact pour le premier mois. Dites-lui que cela fait partie de son travail, et non que c’est un service qu’elle rend, et prévoyez que cela lui coûtera quelques heures par semaine. Ce coût est réel et il a sa place dans votre calcul de ce que coûte la mission, à côté du tarif.
C’est le chevauchement des horaires de travail qui rend cela peu coûteux. Une question posée à onze heures et répondue à onze heures quinze ne coûte presque rien. La même question posée dans un vide d’une journée de travail coûte le reste de la journée, et après deux ou trois expériences de ce genre, les gens cessent de demander. C’est cet échec que vous prévenez.
Membre de l’équipe, sans faire croire qu’il s’agit d’un salarié
Deux erreurs opposées ici, et toutes deux sont courantes. La première consiste à maintenir la personne externalisée structurellement à part : son propre canal, son propre stand-up, son propre backlog. Elle dérive, car elle travaille à partir d’une version périmée du plan, et le temps que quelqu’un s’en aperçoive, une quinzaine de travail est à refaire.
Le deuxième consiste à faire comme si la différence contractuelle n’existait pas. Elle existe. Ils ne sont pas sur votre masse salariale, ils travaillent peut-être avec d’autres clients, leur préavis est différent, et leurs accès devraient être limités à ce qu’exige le travail plutôt qu’à tout. Être honnête là-dessus n’est pas de l’exclusion, et en faire un tabou signifie simplement que personne ne prépare la fin de la mission.
La position praticable est simple : même backlog, même canal, même définition du « terminé », mêmes exigences de revue, même invitation à contester lors d’une discussion de conception. Contrat différent, périmètre d’accès différent, attentes différentes quant à la permanence. Personne n’est troublé par ce dispositif, sauf les responsables qui ne l’ont pas énoncé à voix haute.
À quoi la deuxième semaine devrait ressembler
À la fin de la deuxième semaine, vous voulez que trois choses soient vraies : quelque chose que la personne a écrit est en production, elle a posé au moins quelques questions non triviales, et elle a trouvé au moins un point erroné dans votre installation. Si ces trois choses se sont produites, l’intégration a fonctionné et vous pouvez cesser de la suivre de près.
Si rien de tout cela ne s’est produit, n’attendez pas le deuxième mois pour en chercher la raison. La cause la plus fréquente n’est pas la compétence. C’est que personne n’a rendu la première tâche concrète : la personne a donc passé quinze jours à lire, à rester poliment disponible, et à attendre qu’on lui dise quoi faire.