16 September 20257 min de lecture
Demandez à une équipe ce qu’elle n’externaliserait jamais et vous obtiendrez une longue liste énoncée avec une certaine chaleur. Demandez-lui pourquoi, point par point, et l’essentiel de la liste se dissout. Il en reste en général trois ou quatre choses, dont au moins une que personne n’avait mentionnée.
Il vaut la peine de comprendre pourquoi le sujet est brûlant, car il ne porte pas vraiment sur le travail. Il porte sur la peur de ne plus comprendre son propre produit. Cette peur est justifiée. Elle vise simplement la mauvaise cible : ce qui vous protège n’est pas de garder tel module en interne, c’est de conserver la capacité de juger si tout cela vaut quelque chose.
Les décisions sur ce qu’il faut construire
Le premier élément véritablement à garder n’est pas du code du tout. Décider de ce que doit faire le produit, pour qui et dans quel ordre est le travail qui ne peut pas être délégué à l’extérieur, car il est l’accumulation de tout ce que vous avez appris de vos clients et de votre marché. Un prestataire peut conseiller, et un bon prestataire contestera un plan qu’il juge mauvais. Il ne peut pas en être propriétaire.
Cela compte pratiquement, pas philosophiquement. Tout dispositif d’externalisation qui dérive le fait parce que la direction produit s’est discrètement déplacée vers celui qui était le plus proche du code. Cela se produit progressivement, par petites décisions prises en l’absence de réponse, et quand quelqu’un s’en aperçoit, la feuille de route appartient aux gens qui se trouvaient disponibles au moment où chaque question s’est posée. Le remède est peu glorieux : quelqu’un en interne détient le backlog, et les questions ont un responsable qui répond dans la journée.
Les parties du système qui se cumulent
Certains codes valent d’autant plus cher qu’une même personne a vécu longtemps avec eux. Le moteur de tarification, la logique d’appariement, le modèle, la structure de données centrale autour de laquelle tout le reste s’organise. Chaque décision qu’il contient dépend de cent décisions antérieures, dont la plupart n’ont jamais été écrites et dont certaines étaient mauvaises pour des raisons que seul un rescapé peut expliquer.
C’est l’élément à conserver classique, et il est réel. Mais soyez honnête sur sa taille. Dans la plupart des systèmes, il représente une minorité du code et une minorité du backlog. Le reste du dépôt, ce sont des écrans d’administration, des intégrations, du reporting, des migrations, des tests, et la longue traîne de fonctionnalités qui existent parce qu’un client les a demandées. Garder en interne le cœur qui se cumule n’oblige pas à tout garder en interne, et confondre les deux est ainsi que des équipes finissent avec des ingénieurs expérimentés qui écrivent des exports CSV.
Les clés, et la responsabilité qui va avec
Le troisième élément à conserver est la maîtrise de votre propre infrastructure et de vos données. Non pas le travail d’exploitation, qui s’externalise constamment et avec succès, mais la propriété : les comptes, les noms de domaine, les identifiants de production, l’organisation cloud, la capacité de révoquer n’importe quel accès en un après-midi.
Pour un acheteur européen, c’est aussi une position juridique et non une préférence. Si des données personnelles sont en jeu, vous restez le responsable de traitement, l’accord de traitement des données décrit ce que votre prestataire peut en faire, et aucun contrat ne détourne de vous l’attention du régulateur. La même logique vaut pour la cession de propriété intellectuelle : le travail produit pour vous devrait vous appartenir au fur et à mesure de sa production, et non vous être cédé en fin de projet, quand le rapport de force a changé de camp.
- Les comptes cloud et de noms de domaine au nom de votre entreprise, le prestataire y étant ajouté comme utilisateur
- Les secrets de production détenus par vous, délivrés au prestataire, révocables sans son concours
- Une gestion de code source qui vous appartient, les collaborateurs du prestataire y figurant comme membres et non comme propriétaires
- Un accord de traitement des données signé avant que la moindre donnée réelle ne soit touchée, et non après le premier incident
- Une cession de propriété intellectuelle rédigée pour prendre effet en continu, et non au paiement final
La capacité à évaluer le travail
L’élément à conserver que personne ne nomme est le jugement technique. Quelqu’un de votre côté doit être capable de regarder ce qui revient et de savoir si c’est bon. Non pas de relire chaque ligne, ce qui n’est ni réaliste ni le sujet, mais de distinguer une approche solide d’une approche qui sonne plausible, et de remarquer quand les réponses à ses questions commencent à devenir plus floues.
Les équipes perdent cela par accident. Elles externalisent une compétence, la dernière personne en interne qui la comprenait s’en va, personne ne la remplace parce que le travail est couvert, et deux ans plus tard l’entreprise ne peut plus évaluer ses propres systèmes. À ce stade, vous ne pilotez plus un prestataire : vous lui faites confiance. Cela peut bien se passer. Ce n’est pas une position que vous choisiriez délibérément.
Ce qui ressemble à des éléments à conserver et n’en est pas
Vient ensuite la partie de la liste que l’on défend le plus fort et dont la conservation coûte le plus cher.
- Tout ce que l’on défend en disant que c’est trop compliqué à expliquer. Si cela ne peut pas être expliqué, cela ne peut pas non plus être confié à un nouveau salarié : vous avez alors un problème de documentation plutôt qu’une question d’externalisation.
- Un travail gardé en interne parce qu’il est sensible, où « sensible » veut dire gênant plutôt que confidentiel. Un système hérité négligé ne devient pas moins négligé en restant privé.
- Le support et l’exploitation, gardés en interne au nom de la proximité client bien plus souvent que l’expérience client ne le justifie, en particulier en dehors de vos propres horaires.
- L’assurance qualité, souvent traitée comme une fonction centrale tout en étant la moins dotée en interne, et fréquemment le gain rapide le plus net qu’apporte une équipe externe.
- La réécriture dont tout le monde convient qu’elle est nécessaire et pour laquelle personne n’a le temps, gardée en interne dans le principe et non faite dans les faits pendant des années.
Le point commun est que ces choix sont défendus par attachement plutôt que par analyse. Une discipline utile consiste à exiger une raison qui survive à une question de relance. Pourquoi cela doit-il rester interne ? Parce que c’est le cœur de métier. Pourquoi est-ce le cœur de métier ? Si la seconde réponse répète la première, l’élément appartient probablement à l’autre liste.
Comment faire ce tri sur votre propre backlog
Prenez votre backlog actuel et rangez chaque élément dans l’une de trois catégories : il décide de ce qu’est le produit, il se cumule à l’intérieur du cœur, ou il doit simplement être bien fait. Faites-le à deux plutôt que seul, car les désaccords sont l’endroit où se trouve l’information utile.
Appliquez ensuite un test à la troisième catégorie. Quelqu’un qui ignore l’histoire de votre entreprise pourrait-il dire si le travail a été correctement fait ? Si oui, le travail a des critères de recette lisibles et peut sortir de la maison, soit en régie où vous le dirigez, soit en livraison gérée où le prestataire détient le résultat. Si non, ce travail n’a pas besoin de rester interne pour toujours, mais il lui faut une définition du « terminé » avant d’aller où que ce soit.
Ce que vous protégez n’est pas une liste de fichiers. C’est la capacité de décider, la connaissance qui se cumule, les clés, et une personne capable de vous dire la vérité sur le travail. Tout le reste est une question d’organisation.