Externaliser son développement : les six questions qui décident du résultat

Les délégations de développement qui tournent mal ne tournent presque jamais mal sur la technique. Le code finit par exister. Ce qui manque, six mois plus tard, c'est la possibilité de savoir où en est le projet, de le reprendre ailleurs, ou simplement de joindre quelqu'un un mardi après-midi.

Les six questions qui suivent se posent avant de signer. Elles ne demandent aucune compétence technique. Et ce qu'elles révèlent tient moins au contenu de la réponse qu'à la vitesse à laquelle elle arrive : une équipe qui a déjà réglé ces sujets répond en une phrase, sans consulter personne.

1. Qui écrit le code, nommément ?

Demandez des noms, des rôles et un engagement écrit sur la composition de l'équipe. Pas un organigramme : les personnes qui travailleront réellement sur votre projet.

« Nos ressources s'en occuperont » signifie que vous ne saurez jamais qui travaille pour vous, ni combien de projets cette personne mène en parallèle. Ce n'est pas nécessairement malhonnête — c'est le fonctionnement normal d'une structure qui vend du volume. Mais cela change ce que vous achetez : une capacité de production, pas une équipe.

Le signal : une réponse qui donne des prénoms sans hésiter. Une réponse qui décrit un processus au lieu de personnes vous dit que la question ne s'était jamais posée.

2. À qui appartient le dépôt de code ?

La bonne réponse est : à vous, dès le premier commit. Pas à la livraison, pas au paiement du solde — dès le premier jour.

Un dépôt hébergé sur le compte du prestataire crée une dépendance qui ne se voit pas tant que tout va bien. Le jour d'un désaccord — sur une facture, sur un retard, sur un choix technique — il devient un moyen de pression. Et le jour où le prestataire disparaît, ce qui arrive aussi, il devient un problème sans solution.

Le coût de faire les choses correctement est nul : créer l'organisation à votre nom et y inviter l'équipe prend dix minutes. C'est précisément pour cela que le refus est instructif.

Le signal : une hésitation. Il n'y a aucune raison technique d'héberger le code ailleurs que chez le client.

3. Comment vais-je voir l'avancement ?

La mauvaise réponse est un pourcentage. « Nous sommes à 70 % » est une phrase qui ne veut rien dire : les 30 % restants contiennent l'intégration, les cas particuliers et les corrections, c'est-à-dire l'essentiel du temps. Un projet reste à 70 % pendant des mois.

La bonne réponse est une démonstration régulière — toutes les semaines, toutes les deux semaines — d'une chose qui fonctionne, montrée en direct, sur un environnement que vous pouvez ouvrir vous-même ensuite. C'est le seul indicateur d'avancement qu'on ne peut pas arranger.

Le signal : la réponse mentionne un environnement accessible en permanence, pas une démonstration sur rendez-vous.

4. Qui répond en cas d'incident, et sous quel délai ?

Trois éléments, et il les faut tous les trois : un nom, un canal, un délai écrit. Un seul manquant, et il n'y a pas d'engagement — seulement une intention cordiale, qui vaut ce que vaut la disponibilité de la personne ce jour-là.

Précisez ce qui compte comme incident. « Le site est en panne » est simple. « Le formulaire de contact n'envoie plus rien depuis une semaine » l'est moins, et c'est pourtant le cas le plus fréquent : personne ne s'en aperçoit, parce que rien n'a l'air cassé.

Le signal : un délai chiffré, distinct selon la gravité. Un délai unique pour tout signale un engagement qui n'a jamais été éprouvé.

5. Comment se passe la sortie ?

La question dérange, et c'est pour cela qu'elle doit être posée au début. À la fin, elle se pose dans un rapport de force défavorable : vous avez besoin de partir, l'autre le sait.

Trois choses à obtenir par écrit : la documentation d'installation permettant à une autre équipe de faire tourner le projet, le transfert des accès — hébergement, domaine, services tiers, comptes de messagerie —, et une période de recouvrement pendant laquelle l'équipe sortante reste joignable.

Une bonne réponse ici est un signe de confiance en soi. Un prestataire qui sait que son travail se défend n'a pas peur d'organiser son propre remplacement.

6. Qu'est-ce qui n'est pas compris ?

La bonne réponse est une liste. « Tout est compris » n'est pas une réponse : la reprise des contenus existants, la formation, l'hébergement, les corrections après la garantie, la rédaction des textes et la traduction sont des postes qui coûtent, et chacun apparaîtra tôt ou tard.

Nommer ce qui est exclu, même sans le vendre, évite qu'il ressurgisse en cours de route comme une évidence — pour l'une des deux parties seulement.

Le cas de l'équipe à l'étranger

Trois objections reviennent, et elles n'ont pas le même poids.

• Le fuseau horaire est le faux problème le mieux installé. Quelques heures d'écart signifient surtout que le travail avance pendant que vous dormez, et qu'une question posée en fin de journée trouve sa réponse au réveil. Au-delà de six ou sept heures, en revanche, il faut organiser explicitement une plage commune.
• La langue de travail compte réellement, et pas au niveau qu'on croit : le vocabulaire technique circule sans effort. Ce qui se perd, ce sont les nuances d'une réunion de cadrage — un « ce serait bien de » qui voulait dire « c'est indispensable ».
• Le droit applicable mérite trois lignes dans le contrat et pas une réunion. Précisez la juridiction compétente et la propriété intellectuelle, et passez à autre chose.

Deux moments profitent d'une présence physique : le cadrage initial et les ateliers avec les utilisateurs finaux. Tout le reste — le développement, les revues, les mises en production, le support — se fait aussi bien à distance, à condition que la cadence de livraison soit régulière. C'est elle qui remplace la surveillance, pas l'inverse.

Une équipe qu'on voit livrer toutes les semaines n'a pas besoin d'être surveillée. Une équipe qu'on ne voit pas livrer ne le devient pas parce qu'elle est dans le bureau d'à côté.

Ce qui reste vrai quelle que soit l'équipe

La plupart des organisations ne choisissent pas entre interne et externe : elles mélangent les deux, et durablement. Une équipe interne qui connaît le métier, un renfort externe sur les compétences rares ou sur les périodes chargées. Les six questions ci-dessus valent aussi pour un recrutement — la propriété du code, la visibilité et la documentation de sortie ne sont pas des sujets de sous-traitance, ce sont des sujets de gestion.

Notre page Développement Web & Mobile décrit la façon dont nous travaillons sur ces six points. Si vous préparez une consultation, envoyez-nous votre besoin : nous répondons aux six questions par écrit avant toute proposition.