Scale-ups post-Series A : tenir la roadmap IA promise au board

Une scale-up qui vient de boucler une Series A ou une Series B vit douze mois de pression simultanée. La pression du recrutement, parce que la moitié des fonds levés sert à passer de quinze à quarante personnes en un an. La pression de la roadmap, parce que le pitch deck a vendu aux investisseurs des features qui figurent maintenant dans des plans à six et douze mois. Et, depuis 2024, la pression spécifique de l'IA — quasiment toutes les thèses d'investissement post-2023 mentionnent une dimension IA, qu'elle soit centrale ou complémentaire.

Le problème opérationnel est connu : recruter un Head of AI et son équipe prend quatre à six mois si tout va bien, le temps que cette équipe livre quelque chose de production-ready, on est à neuf à douze mois après la levée. Le board, lui, attend des signes de progression à la première review trimestrielle.

Trois mauvaises réponses

Face à cette pression, les équipes dirigeantes répondent souvent par l'une de trois solutions, qui ont toutes leurs limites.

La première : faire bricoler la feature par l'équipe produit existante en parallèle de leurs missions principales. C'est l'option la moins coûteuse en apparence. Elle produit un résultat visible vite, qui dégrade durablement le moral et la qualité du produit core. Les ingénieurs senior partent au bout de six mois, fatigués d'avoir empilé deux jobs.

La deuxième : sortir un POC marketing, c'est-à-dire une démo qui tourne en environnement contrôlé et qu'on montre au board sans la mettre en production. Cette option achète du temps, mais elle est risquée si un client ou un journaliste demande à essayer. Et elle reporte le vrai travail sans le réduire.

La troisième : prendre une grosse ESN pour livrer la feature à grande vitesse, à un budget de plusieurs centaines de milliers d'euros. Le risque ici n'est pas le coût, c'est que la feature livrée soit déconnectée de l'architecture interne — un système parallèle que l'équipe interne, une fois recrutée, devra réécrire ou maintenir à contrecœur.

L'option intermédiaire qu'on voit fonctionner

L'approche qui produit les meilleurs résultats chez les scale-ups que nous accompagnons consiste à faire livrer la v1 par un partenaire externe qui s'engage à livrer dans l'architecture cible — celle que l'équipe interne héritera —, avec un transfert de propriété complet à la fin. Pas un sous-système isolé, pas une démo séparée, pas un wrapper temporaire à jeter ensuite. Le code livré est celui que l'équipe interne reprendra.

Cette option suppose deux conditions techniques. D'abord, que le partenaire externe travaille dans la stack du client, ou qu'il livre dans une stack standard que les futurs recrutements maîtriseront. Pas dans une plateforme propriétaire qu'il faudra contourner ensuite. Ensuite, que la modélisation du domaine — les concepts métier de la scale-up — soit documentée et alignée avec le reste du système. Faute de quoi la feature IA, même livrée, ne s'intègre pas dans le produit principal.

Synchroniser avec le recrutement

Le moment idéal pour démarrer un partenariat externe, c'est tôt après la levée — semaine quatre ou six —, en parallèle du début du process de recrutement du Head of AI. La v1 livre vers la semaine quatorze, ce qui correspond à peu près au moment où le Head of AI prend son poste. La transition se fait en deux à quatre semaines, pendant lesquelles le partenaire externe continue à supporter avant de céder la propriété.

Ce séquencement a un autre avantage : un Head of AI à qui on présente une feature en production, avec du code propre et de la documentation, est plus facile à recruter qu'un Head of AI à qui on demande de tout construire depuis zéro. La v1 livrée devient un argument de recrutement.