Ce que signifie sous-traiter le cœur : un transfert de pouvoir
Quand un éditeur logiciel confie le développement de son algorithme principal à une agence ou un freelance externe, il transfère trois types de pouvoir : le pouvoir de définir le rythme des évolutions (désormais contraint par les disponibilités du prestataire), le pouvoir de protéger les algorithmes (désormais dans la tête et les disques d’un tiers), et le pouvoir de réagir rapidement aux évolutions du marché (désormais médiatisé par un contrat et un planning).
La rupture avec le sous-traitant — pour raison économique, départ de l’équipe, rachat du prestataire — place l’éditeur dans une situation de dépendance critique sans possibilité de réaction rapide. La documentation technique est souvent incomplète, le code non commenté, les tests absents. Le coût de reprise en main dépasse régulièrement le coût économisé sur la sous-traitance.
Les signes avant-coureurs d’une dépendance de sous-traitance
Trois signaux indiquent qu’une dépendance de sous-traitance est devenue problématique : aucun ingénieur interne ne comprend le code du composant critique ; toute modification majeure nécessite l’accord et le planning du prestataire ; les secrets techniques (algorithmes, données d’entraînement, modèles) sont dans des systèmes non contrôlés par l’éditeur.
Un quatrième signal, plus subtil : le prestataire commence à travailler pour des concurrents directs avec les mêmes bases de code. Ce n’est pas nécessairement illégal si les contrats sont mal rédigés, mais c’est un transfert effectif de l’avantage compétitif. Des clauses d’exclusivité sectorielle sur les composants critiques, quand la sous-traitance est temporairement inévitable, limitent ce risque.
Inscrire l’interdiction dans la gouvernance du groupe
La décision de ne jamais sous-traiter le cœur technique doit figurer dans la charte de gouvernance du groupe — pas dans un mémo, mais dans un document opposable aux dirigeants de filiales. Cette clause définit précisément quels composants sont « critiques » (liste mise à jour annuellement par le CTO du groupe), et exige une décision du conseil d’administration pour toute dérogation temporaire.
Cette formalisation protège les décisions à long terme contre les pressions à court terme. Un directeur commercial qui promet une fonctionnalité en trois semaines ne peut pas contourner l’interdiction de sous-traitance critique sans déclencher un processus formel. La gouvernance sert ici de garde-fou contre les décisions tactiques qui compromettent la stratégie.
Questions fréquentes
Peut-on faire appel à des freelances pour des composants critiques sans créer une dépendance ?
Oui, sous trois conditions : le freelance travaille sous supervision d’un ingénieur interne qui comprend le code produit ; les droits patrimoniaux sur le code sont cédés intégralement à l’éditeur dans le contrat ; et la documentation technique est produite en parallèle du code, pas après. Un freelance dans ces conditions est un accélérateur, pas une dépendance.
Comment reprendre en main un composant déjà sous-traité ?
Par une opération de réinternalisation progressive : audit de code existant, recrutement d’un ingénieur interne sur le composant, période de shadow (l’ingénieur interne travaille en parallèle du sous-traitant), puis bascule. Prévoir 6 à 18 mois selon la complexité et l’état de la documentation. Ne pas tenter une reprise précipitée sans phase de parallélisation.