Travailler avec des startups sans gaspiller leur temps ni le vôtre

Pour bien travailler avec des startups, partez d'un problème que vous avez déjà décidé de résoudre, donnez à une seule personne le pouvoir de décider vite, et menez un pilote court et rémunéré, avec des critères de réussite écrits avant le démarrage et un contrat prêt en cas de succès. La plupart des collaborations entre grands groupes et startups échouent non parce que la technologie est mauvaise, mais parce que la grande organisation avance à son propre rythme, change d'avis et traite le pilote comme une expérience sans conséquence. Pour une startup, un « proof of concept » de six mois non rémunéré qui ne mène nulle part peut faire la différence entre survivre et disparaître.

Cet article porte sur la mécanique pratique. Pour une vue d'ensemble des organisations qui résolvent des problèmes ensemble, voir Innovation d'écosystème.

Pourquoi ces partenariats tournent mal

Les deux parties ne vivent pas au même rythme. Une startup compte sa trésorerie disponible en mois ; une grande organisation vote ses budgets une fois par an. Les fondateurs d'une startup décident en une journée ; une décision dans un grand groupe peut exiger quatre signatures et un passage par les achats. Aucun des deux n'a tort, mais cet écart produit sans cesse les mêmes échecs :

• Le piège du scouting. Une équipe innovation rencontre cinquante startups, organise une journée de démonstration, et n'a aucune unité métier prête à travailler avec l'une d'elles.
• Le pilote sans fin. Le test s'éternise parce que personne n'a défini ce que « réussir » voulait dire, et donc personne ne peut le constater.
• Le conseil gratuit. La startup passe des semaines à adapter son produit à vos exigences, sans être payée, puis n'a plus de nouvelles.
• Le mur des achats. Le pilote fonctionne, l'unité métier le veut, puis le référencement fournisseur, la revue de sécurité et l'appel d'offres prennent un an.

Le remède n'est pas l'enthousiasme. C'est de la structure de votre côté.

Comment procéder, étape par étape

1. Partir d'un problème porté par une unité métier. Pas « nous voulons explorer l'IA », mais un problème nommé, avec un responsable nommé, qui dispose d'un budget et changera sa façon de travailler si une solution convient. Formulez-le sous forme de question « Comment pourrions-nous » : « Comment pourrions-nous réduire le temps que notre équipe sinistres passe à lire des formulaires manuscrits ? » Si aucune unité métier n'accepte d'en être responsable, n'approchez pas encore de startups.

2. Choisir le type de relation recherché. Il en existe en gros quatre, et les confondre fait perdre du temps :

   • Acheter : vous devenez client d'un produit qui fonctionne déjà. Le plus rapide et le plus courant.
   • Piloter : vous testez un produit opérationnel dans votre contexte avant de l'acheter.
   • Co-développer : vous construisez ensemble quelque chose de nouveau, généralement avec des questions de propriété intellectuelle partagée.
   • Investir : vous prenez une participation. Une autre équipe, d'autres conditions, un autre horizon de temps. L'approche « venture client », popularisée par le Startup Garage de BMW à partir de 2015, soutient que la plupart des organisations devraient commencer par acheter et piloter plutôt qu'investir, car devenir client d'une startup est ce qui crée le plus vite de la valeur pour les deux parties.

3. Dégager votre circuit interne avant de chercher. Avant de contacter qui que ce soit, identifiez ce dont votre organisation a besoin pour payer un petit fournisseur : référencement, revue de sécurité et de données, modèle de contrat, délais de paiement. Convenez d'une voie rapide pour les pilotes en dessous d'un certain montant. Si vous ne pouvez pas payer une startup dans les semaines qui suivent un pilote réussi, réglez ce point d'abord.

4. Chercher avec le problème, pas avec un appel à « l'innovation ». Décrivez le problème, les données et l'environnement disponibles, et ce à quoi ressemble un bon résultat. Les startups qui ne peuvent pas le résoudre se retireront d'elles-mêmes. Établissez une liste restreinte à l'aide d'une courte matrice de décision pondérée : adéquation au problème, maturité du produit, capacité à livrer dans votre environnement, équipe.

5. Rendre une décision en quelques jours, pas en quelques mois. Rencontrez les startups retenues, puis décidez. Dites à celles que vous écartez qu'elles sont écartées, et pourquoi. Le silence coûte plus cher à une startup qu'un refus.

6. Rédiger ensemble le plan du pilote, sur une page. Indiquez l'hypothèse, ce qui sera mesuré, le seuil de réussite, la durée, qui le soutient de votre côté et ce qui se passe s'il est concluant. Le format du test d'hypothèse convient bien. Servez-vous de la cartographie des hypothèses pour trouver l'hypothèse la plus risquée, et testez-la en premier.

7. Payer le pilote. Même une rémunération modeste change la relation : les deux parties le prennent au sérieux, la startup peut y affecter des personnes, et votre organisation a déjà franchi les étapes d'achat dont elle aura besoin plus tard.

8. Le doter de moyens de votre côté. Un pilote a besoin d'un responsable métier qui l'utilisera, d'un interlocuteur technique capable d'ouvrir les accès, et de quelqu'un qui lève les blocages. Une matrice RACI pour le pilote prend dix minutes et fait gagner des semaines.

9. Décider à la date fixée. À la fin, comparez les résultats au seuil convenu. Concluant : on passe à un contrat aux conditions fixées à l'avance. Non concluant : on arrête et on le dit. « Prolongeons un peu » est la réponse qui fait perdre son temps à tout le monde ; si vous prolongez, faites-le une seule fois, pour une raison précise, avec une nouvelle date.

10. Préparer le déploiement avant la fin du pilote. Qui l'exploitera, à quels systèmes il se connecte, qui forme les utilisateurs. Une check-list de déploiement évite que le passage de relais ne s'enlise.

À faire et à éviter

À faire

• Nommer un responsable métier avant de contacter la moindre startup.
• Dire tôt aux startups ce que vous pouvez payer, en combien de temps et par quel circuit.
• Convenir des critères de réussite avant le démarrage du pilote.
• Payer les pilotes, même modestement.
• Protéger la propriété intellectuelle de la startup. Soyez clair sur les droits dont vous avez besoin, et n'en demandez pas davantage.
• Les présenter à d'autres unités si cela fonctionne. Votre recommandation peut compter davantage que le contrat.

À éviter

• Organiser des journées de démonstration sans responsables capables d'acheter dans la salle.
• Demander du développement sur mesure pendant un pilote. Testez ce qui existe.
• Changer de responsable en cours de pilote sans véritable passation.
• Lancer la revue juridique après la réussite du pilote. Menez-la en parallèle.
• Utiliser les pilotes pour récolter des idées gratuites en vue d'un développement interne. Les startups se parlent, et votre réputation circule.
• Mesurer votre programme au nombre de startups rencontrées. Mesurez combien de pilotes sont devenus des contrats.

Exemple fictif

Exemple fictif. Un assureur de taille moyenne aux Pays-Bas voulait réduire le temps que son équipe sinistres consacrait aux dégâts des eaux chez les particuliers. Le directeur des sinistres a accepté de porter le problème et a réservé un petit budget de pilote.

Avant toute recherche, le responsable innovation a passé trois semaines avec les achats pour convenir d'une voie rapide : les pilotes sous un certain montant pouvaient utiliser un modèle de contrat court et passer une revue de sécurité allégée, à condition qu'aucune donnée client ne sorte des systèmes de l'assureur. L'appel décrivait le problème, les données de sinistres anonymisées disponibles et l'objectif : réduire nettement le temps de traitement des sinistres simples tout en maintenant une précision au moins égale au niveau actuel.

Douze startups ont répondu. Quatre ont été présélectionnées à l'aide d'une matrice pondérée ; deux ont été reçues en entretien ; une a été choisie en dix jours, et les trois autres ont été informées des raisons de leur non-sélection. Le plan du pilote tenait sur une page : huit semaines, trois gestionnaires de sinistres, un ensemble défini de types de sinistres, un seuil de réussite et un prix de licence convenu à l'avance en cas de succès.

Le pilote a atteint le seuil sur la plupart des types de sinistres et l'a manqué sur un. Le directeur des sinistres a signé le contrat pour les types concluants, et le type restant a fait l'objet d'un second test, plus court.

Les questions qu'on nous pose

Faut-il payer les startups pour un proof of concept ? Oui, dans la plupart des cas. Un pilote rémunéré est pris au sérieux par les deux parties, permet à la startup d'y affecter des personnes et oblige votre organisation à franchir les étapes d'achat dont elle aura besoin de toute façon. Les proofs of concept non rémunérés ont tendance à dériver et favorisent les startups qui peuvent se permettre de travailler gratuitement, pas celles qui ont le meilleur produit.

Combien de temps doit durer un pilote avec une startup ? Le temps nécessaire pour mesurer le résultat convenu, et pas davantage. Pour un produit opérationnel dans un processus défini, six à douze semaines sont courantes. Si le pilote demande six mois, vous êtes probablement en co-développement, ce qui appelle d'autres conditions.

À qui appartient la propriété intellectuelle dans un pilote entre un grand groupe et une startup ? En règle générale, la startup conserve la propriété de son produit et de tout ce qu'elle apporte, et vous conservez vos données et tout ce que vos équipes créent. Convenez par écrit des droits dont vous avez besoin pour exploiter les résultats. Votre service juridique tranche les détails ; le principe est de ne demander que ce dont vous avez réellement besoin.

Pour aller plus loin

Utilisez les questions « Comment pourrions-nous » pour cadrer le problème avant de chercher, une matrice de décision pondérée pour établir la liste restreinte, et un test d'hypothèse pour rédiger le plan du pilote. Pour la vue d'ensemble, lisez Innovation d'écosystème ; pour un appel public adressé à de nombreuses startups à la fois, voir Open innovation, co-création ou crowdsourcing, et pour les partenaires de recherche, Innover en partenariat avec les universités.