Sept questions à poser à un partenaire technique avant de signer

La plupart des fondateurs choisissent un partenaire technique comme ils choisiraient un restaurant : une bonne conversation, un joli portfolio, une intuition. Cela fonctionne très bien pour un dîner. Pour une décision qui façonnera votre produit pendant l'année à venir, ce n'est pas suffisant.

Ces sept questions sont conçues pour révéler ce qu'un pitch deck ne montre pas. Chacune vise un mode d'échec précis.

1. À qui appartient le code, et à partir de quand ?

C'est la question que les fondateurs oublient le plus souvent, et la plus difficile à corriger après coup.

Ce que vous vérifiez : si la propriété intellectuelle vous revient progressivement, seulement après le paiement final, ou n'est pas explicitement précisée.

Une réponse solide : « Tout vous appartient dès le premier commit. C'est une clause permanente du contrat, indépendante du paiement final. » Certains partenaires sérieux conditionnent tout de même le transfert complet de PI au paiement final, comme protection commerciale standard, ce qui est raisonnable à condition de le dire clairement plutôt que vaguement.

Le signal d'alerte : une hésitation, ou une réponse évoquant « après la fin de la mission » sans déclencheur précis. Si un partenaire ne peut pas indiquer clairement quand vous devenez juridiquement propriétaire du travail, présumez l'interprétation la moins favorable.

2. Qu'est-ce qui n'est exactement pas inclus dans ce prix ?

Tout devis sous-entend une limite. La question est de savoir si l'autre partie a réfléchi à où elle se situe.

Ce que vous vérifiez : si la liste des exclusions est précise ou générique.

Une réponse solide est longue et ennuyeuse : pas de frais d'API tiers, pas de rédaction de contenu, pas de migration de données depuis l'ancien système, le support s'arrête au jour 30, les applications mobiles natives font l'objet d'un devis séparé. La précision ici est bon signe, pas mauvais.

Le signal d'alerte : « Ne vous inquiétez pas, on gérera ce qui se présente. » Cela paraît généreux. Cela signifie que la limite n'est pas définie, et les limites non définies se redessinent en faveur du partenaire une fois le travail commencé et le coût de changement de votre côté.

3. Quel a été votre dernier projet qui s'est mal passé, et pourquoi ?

Chaque agence en a un. La question n'est pas de savoir si quelque chose a mal tourné, mais s'ils peuvent le décrire honnêtement.

Ce que vous vérifiez : la lucidité et une cause concrète, vérifiable.

Une réponse solide nomme un échec précis : un périmètre sous-estimé parce qu'une intégration de paiement s'est révélée plus complexe que prévu, et ce qui a changé dans leur processus depuis. C'est un partenaire qui a livré suffisamment pour avoir des cicatrices.

Le signal d'alerte : « On n'a pas vraiment d'échecs, on livre toujours. » Personne n'a un taux de réussite de 100 %. Cette réponse signifie soit qu'on n'est pas honnête avec vous là, maintenant, au téléphone, avant même d'avoir rien signé, soit qu'un mauvais résultat pour le client n'est pas considéré comme un échec digne d'être mentionné.

4. Que vais-je voir chaque semaine pendant la construction ?

Cette question teste si vous achetez un processus ou une promesse.

Ce que vous vérifiez : un livrable concret et récurrent, pas un engagement général de communication.

Une réponse solide : une démo fonctionnelle chaque jeudi, une note de sprint écrite chaque vendredi, un environnement de préproduction accessible à tout moment. Ce sont des choses qui existent que quelqu'un pense ou non à envoyer une mise à jour.

Le signal d'alerte : « On vous tiendra informé » ou « comme vous préférez ». Un rythme vague devient une absence de rythme en trois semaines, et à la sixième semaine c'est vous qui courez après le statut au lieu de le recevoir.

5. Qui exactement travaillera dessus, et combien de temps y consacreront-ils ?

Les appels commerciaux sont menés par la personne la plus expérimentée et la plus persuasive de l'entreprise. Cette personne n'est souvent pas celle qui écrit votre code.

Ce que vous vérifiez : des personnes nommées et des pourcentages réels, pas des intitulés de poste.

Une réponse solide : « Un tech lead à 40 %, deux développeurs à 100 %, un designer à 30 %, et je m'occuperai moi-même de la planification des sprints à environ 15 %. » Des pourcentages qui ne forment pas une équipe cohérente, ou qui ajoutent plus de personnes que le budget ne peut raisonnablement supporter, méritent d'être questionnés.

Le signal d'alerte : l'équipe n'est décrite que par des rôles, sans noms, et personne ne peut vous dire qui sera votre interlocuteur au quotidien. On vous vend la réputation d'une entreprise, tandis que votre projet reviendra aux développeurs disponibles cette semaine-là.

6. Que couperiez-vous si mon budget était réduit de 30 % ?

C'est le moyen le plus rapide de savoir si la personne en face de vous a réellement réfléchi à votre produit ou récite un forfait standard.

Ce que vous vérifiez : une réponse immédiate et précise.

Une réponse solide arrive en quelques secondes, parce qu'un partenaire qui comprend votre produit sait déjà quelles fonctionnalités sont porteuses et lesquelles sont accessoires. « Je supprimerais le tableau de bord analytique de l'admin et la deuxième langue, en gardant tout ce qui touche au flux transactionnel principal. »

Le signal d'alerte : un long silence, suivi de « tout est important » ou d'une demande de réfléchir et de revenir vers vous. S'il leur faut trois jours pour identifier ce qui compte le plus dans votre produit, ils ne l'ont pas encore intégré, et cela se verra dans chaque décision de périmètre à venir.

7. Que se passe-t-il le lendemain du lancement ?

Le jour du lancement est abordé dans chaque pitch. Le lendemain, presque jamais, et c'est là que la vraie différence entre un prestataire et un partenaire apparaît.

Ce que vous vérifiez : un plan précis, pas une vague assurance de « support continu ».

Une réponse solide nomme une période définie, un périmètre défini de ce qu'elle couvre, et une étape suivante explicite : 30 jours de correction de bugs inclus, un tableau de bord de supervision mis en place avant la passation, et un forfait ou un contrat de support proposé pour la suite, chiffré dès maintenant plutôt que négocié plus tard sous pression.

Le signal d'alerte : « On est toujours disponibles si besoin. » Ce n'est pas un plan, c'est une phrase conçue pour clore la conversation. Disponibles à quel prix, avec quel délai de réponse, pour quel périmètre de travail ? Si rien de tout cela n'est répondu avant la signature, ce le sera plus tard, selon leurs conditions, quand vous n'aurez plus aucun levier.

Comment utiliser cela en pratique

N'envoyez pas ces questions comme un questionnaire écrit. Posez-les lors d'un appel et écoutez la rapidité et la précision de la réponse, pas seulement son contenu. Une hésitation sur la question un ou quatre en dit plus long que les mots utilisés pour la masquer.

Si vous n'avez le temps que pour deux, posez la 1 et la 6. La propriété vous indique ce que vous achetez réellement. La question du budget révèle si la personne s'est vraiment engagée avec votre produit ou récite un script.

Voici comment nous répondrions nous-mêmes à ces sept questions, par écrit, avant même que vous les posiez : notre exemple de Blueprint montre exactement ce que produit un vrai processus de cadrage, et nos tarifs détaillent ce qui est inclus ou non à chaque niveau. Si vous préférez nous le demander directement, contactez-nous.