Prestataire de confiance, catastrophe technique : ce que j'aurais dû faire dès le départ

"On les connaît, ça va bien se passer."

C'est la phrase la plus chère que j'aie prononcée sur ce projet.

Une agence qu'on avait déjà sollicitée. Des gens sérieux, professionnels, recommandés en interne. Pas un inconnu trouvé sur Malt un vendredi après-midi.

Et pourtant : délais multipliés par deux. Et moi - le CTO censé piloter, pas exécuter - à driver directement les développeurs de l'agence pour débloquer des problèmes techniques qu'ils auraient dû résoudre seuls.

Ce n'est pas une histoire de mauvaise foi. C'est une histoire de gap technique qu'on n'a pas détecté assez tôt. Et que j'aurais pu détecter dès le premier sprint si j'avais appliqué la rigueur que j'aurais appliquée avec un prestataire inconnu.

Voici ce que j'ai compris - trop tard - et ce que je fais maintenant systématiquement.

La confiance relationnelle n'est pas une garantie technique

C'est l'erreur fondamentale, et elle est facile à commettre.

Quand vous avez déjà travaillé avec quelqu'un, vous avez construit une confiance. Cette confiance est réelle. Mais elle porte sur des attributs précis : leur sérieux, leur réactivité, leur façon de gérer un projet, leur relation client.

Elle ne porte pas automatiquement sur leur maîtrise de React Native spécifiquement, ou de n'importe quelle technologie que vous leur confiez pour la première fois.

J'ai confondu les deux. C'est mon erreur, pas la leur.

Ils n'avaient pas prétendu être des experts React Native. J'avais supposé que leur niveau général impliquait une maîtrise spécifique. Cette supposition n'a pas été vérifiée. Elle aurait dû l'être.

La règle que j'aurais dû appliquer : la confiance relationnelle avec un prestataire se qualifie à chaque nouveau contexte technique. Une agence excellente en développement web n'est pas nécessairement solide sur le mobile. Un studio mobile fort sur Flutter ne l'est pas forcément sur React Native. Ce sont des compétences distinctes.

Le premier livrable dit tout - si vous savez quoi regarder

Les signaux étaient là dès la première semaine.

Des choix d'architecture qui m'ont surpris. Des questions qui auraient dû avoir des réponses évidentes pour un profil expérimenté sur cette stack. Une structure de dossiers qui trahissait une approche "on fait comme d'habitude" plutôt qu'une compréhension des contraintes spécifiques du projet.

J'ai mis ça sur le compte du démarrage. "Ils se calent, c'est normal." J'aurais dû en parler immédiatement.

En réalité, le premier livrable d'un prestataire est son vrai entretien technique. Pas l'entretien de vente où il vous montre ses références. Le premier sprint livré, avec du vrai code sur votre vrai projet - c'est là que vous voyez ce dont il est capable.

Ce que j'aurais dû faire à J+7 :

• Passer 2 heures sur le code livré avec un oeil critique sur les décisions d'architecture, pas seulement sur les fonctionnalités
• Poser trois questions précises sur des choix qui m'interrogeaient - pour voir si la réponse était documentée et assumée, ou improvisée
• Fixer explicitement les standards attendus pour la suite, avant que les mauvaises habitudes ne soient installées

Un prestataire solide répond à ces questions sans se braquer. Il a une justification, ou il reconnaît le point et s'ajuste. C'est exactement le signal qu'on cherche.

Driver les devs d'un prestataire, c'est payer deux fois

C'est le symptôme le plus visible - et le plus coûteux - d'un gap technique non adressé.

La mécanique est simple : le prestataire est bloqué sur un problème qu'il n'arrive pas à résoudre seul. Il escalade. Vous intervenez pour débloquer. Vous y passez deux heures. Le problème est résolu. Vous continuez.

Et ça recommence.

Techniquement, vous externalisez le développement. Opérationnellement, vous gardez toute la charge technique. Vous payez la prestation au prix du marché, et vous y ajoutez votre propre temps - le temps le plus cher du projet, parce que c'est le vôtre.

C'est le pire des deux mondes.

Ce pattern a une cause claire : le prestataire n'a pas le niveau de maturité sur la stack pour fonctionner en autonomie sur les problèmes complexes. La solution n'est pas de driver davantage - c'est de l'avoir détecté avant de signer.

Un audit technique au démarrage n'est pas un manque de confiance

C'est la résistance que j'entends parfois quand j'impose maintenant un sprint de qualification avant tout engagement : "on a l'impression d'être mis en examen".

C'est mal comprendre l'objectif.

Un audit technique au démarrage n'est pas là pour surveiller. Il est là pour aligner. Valider que la compréhension de la stack, la façon de structurer le code, et les réflexes d'architecture sont compatibles avec ce que vous voulez construire sur la durée.

C'est dans l'intérêt du prestataire autant que dans le vôtre. Un prestataire qui entre sur un projet avec une mauvaise compréhension des attendus techniques va produire du code qui sera refactorisé, des délais qui vont déraper, et une relation commerciale qui va se détériorer. L'audit précoce évite ça à tout le monde.

La formulation que j'utilise maintenant : "Ce n'est pas une évaluation de votre compétence en général. C'est une qualification de l'adéquation entre votre expertise et ce projet spécifique."

Un prestataire solide comprend ça et le vit bien. C'est aussi un signal en soi.

La méthode : un sprint de qualification avant de signer

Ce que je mets en place systématiquement maintenant, quel que soit le prestataire :

Un sprint d'une semaine sur un périmètre limité, avant l'engagement complet.

Ce sprint n'est pas gratuit - je le paie au tarif normal. Ce n'est pas non plus un POC déguisé pour récupérer du code sans s'engager. C'est un investissement de qualification.

Ce que j'évalue pendant ce sprint :

1. L'autonomie sur les problèmes techniques de leur périmètre. Est-ce qu'ils viennent avec des solutions ou avec des questions qui auraient dû avoir des réponses avant de commencer ?

2. La qualité des choix d'architecture spontanés. Les décisions qu'ils prennent sans que je leur demande - structure des composants, gestion de l'état, nommage, organisation des fichiers - révèlent leur niveau de maturité sur la stack.

3. La façon dont ils réagissent au feedback. Une code review sur du code livré, avec des remarques précises, est le meilleur test de la relation qui s'installerait sur la durée.

4. La capacité à estimer honnêtement. Est-ce que leurs estimations pour la semaine étaient calibrées ? Si non, pourquoi - et est-ce qu'ils l'identifient eux-mêmes ?

À l'issue de ce sprint, vous avez une vraie base de décision. Pas un pitch de vente, pas des références d'autres projets - du vrai code, produit par les vraies personnes qui vont travailler sur votre projet.

Ce que ça change pour un CTO de startup

Quand vous êtes CTO dans une startup early-stage sans équipe tech interne constituée, la gestion des prestataires est souvent la partie la plus consommatrice de votre bande passante.

Paradoxalement, les startups sont celles qui qualifient le moins leurs prestataires - parce qu'elles sont les plus pressées, et que l'audit technique initial ressemble à un ralentisseur.

C'est un calcul qui se retourne systématiquement : une semaine de qualification en amont contre des semaines de retard et de micro-management en aval.

On a livré ce projet React Native. En retard, avec de la sueur, mais on a livré. Et j'ai posé une règle simple depuis ce jour : la confiance se construit, elle ne remplace pas la vérification.

Même avec les gens qu'on connaît. Surtout avec les gens qu'on connaît, parce que c'est là qu'on baisse la garde.