RFP de développement logiciel : pourquoi la plupart des fondateurs non techniques utilisent le mauvais instrument

Une fondatrice à qui nous avons parlé le trimestre dernier a envoyé le même RFP de 11 pages à cinq studios de logiciels. Société pre-seed, deux pilotes enterprise signés, six semaines pour livrer une v1 fonctionnelle au premier client payant. Le RFP était un template qu’elle avait téléchargé sur un blog d’achats : company background, project goals, scope of work, technical requirements, evaluation criteria, deadline. Ça avait l’air professionnel. Ça avait l’air d’être la chose responsable à faire.

Trois studios n’ont pas répondu. Les deux qui ont répondu ont envoyé des propositions séparées de 90 000 dollars sur le même périmètre. Aucun n’a posé la question qui comptait, à savoir si elle avait réellement besoin de tout ce qu’elle avait écrit. Elle a choisi le moins cher. Six mois plus tard elle en était à son troisième chef de projet et son client utilisait toujours un tableur.

Voilà à quoi ressemble un RFP de développement logiciel quand l’instrument ne correspond pas au travail. C’est aussi ce que la plupart des articles qui se positionnent sur cette requête ne voient pas : la question n’est pas comment écrire le RFP, c’est de savoir si le RFP est la bonne chose à écrire.

Ce qu’est vraiment un RFP de développement logiciel

Un RFP, ou Request for Proposal, est un document formel d’achats. Un acheteur l’envoie à une shortlist connue de vendors en décrivant ce qu’il faut construire, dans quel délai, sous quelles contraintes, et comment les offres seront évaluées. Les vendors répondent par une proposition structurée : périmètre, équipe, calendrier, prix, références. L’acheteur évalue les réponses contre les critères du document et choisit l’offre gagnante.

L’instrument existe parce que faire des achats à grande échelle est compliqué. Quand un département IT d’une Fortune 500 achète un CRM, qu’une agence régulée contracte un intégrateur, ou qu’un réseau hospitalier sélectionne un EHR, le RFP impose trois choses : un terrain équitable pour les vendors, une trace documentaire de la décision, et un périmètre contractuel défini pour que l’acheteur ne soit pas seul à porter la responsabilité quand le projet déraille. Pour ce type d’achat, le RFP est le bon document.

Pour un fondateur non technique qui commande une construction custom au pre-seed, au seed ou en Série A, ces trois propriétés ne s’appliquent pas. Les fournisseurs sont une petite communauté, pas un marché d’achats. Il n’y a pas de comité d’audit à satisfaire. Et le périmètre n’est pas encore défini. Il ne peut pas l’être, parce que la raison pour laquelle le fondateur externalise est justement qu’il ne sait pas, au niveau des exigences, ce qu’il faut construire.

Pourquoi les fondateurs s’en remettent quand même au RFP

Il y a en général trois déclencheurs. Aucun n’est “le RFP est le meilleur instrument pour ce travail.”

Le premier est l’héritage professionnel. Le fondateur a passé dix ans en finance, en conseil ou à un poste corporate senior avant de lancer la société. Chaque décision d’achat de sa vie d’avant utilisait un RFP. C’est la mémoire musculaire du “on dépense du vrai argent et il faut faire attention.” Quand le budget est de 150 000 dollars et que le projet survivra au prochain tour de financement, le RFP ressemble à la version adulte de “demander trois devis.”

Le deuxième est la peur de se faire avoir. Douleur ICP n°2 : chaque freelance s’est mal terminé. Des amis ont levé en pre-seed, payé 200 000 dollars à une agence et reçu une app à moitié fonctionnelle. Le fondateur s’en remet au RFP parce que le document ressemble à une protection : périmètre clair, livrables clairs, pénalités claires.

Le troisième est l’optique investisseur. Un membre du board ou un advisor a dit “prends trois devis.” Un CFO qui n’a jamais bossé en produit a suggéré de formaliser le processus. Le RFP est l’artefact qui prouve que la due diligence a eu lieu.

Les trois déclencheurs sont légitimes. L’erreur est de conclure que le RFP répond à l’un d’entre eux. La prudence, la protection et la due diligence en pre-seed ne ressemblent quasiment à rien des achats en grande entreprise.

Trois problèmes du RFP pour du logiciel custom en phase amont

Problème 1 : le problème de périmètre

Un RFP demande à l’acheteur de spécifier ce qu’il veut construit. La Section 3 est toujours “Périmètre et exigences du projet.” Pour du logiciel packagé, ça marche : l’acheteur sait qu’il veut un CRM qui fait X, Y et Z, et les vendors chiffrent contre ces fonctionnalités. Pour du logiciel custom en phase amont, le fondateur ne sait pas encore ce qu’il veut. Il sait la douleur du client, il sait le résultat business dont il a besoin, et il a une hypothèse sur la première tranche du système. Tout l’intérêt de travailler avec un partner est de réduire la distance entre l’hypothèse et le produit livré.

Quand le RFP force le fondateur à écrire 40 exigences qu’il n’a pas validées, deux mauvaises choses arrivent. Il sur-spécifie, parce que laisser des cases vides dans la section des exigences a l’air peu professionnel. Et les vendors chiffrent contre le périmètre sur-spécifié, pas contre le vrai problème. Les 40 exigences deviennent le contrat, et chaque écart devient un avenant. Le fondateur a transformé une intuition en livrable avant d’avoir parlé à un seul ingénieur.

Les studios qui voient ça (les bons) diraient au fondateur de jeter la section des exigences et de partir du problème client. Ils ne le diront pas à l’intérieur de la proposition, parce que le format de la proposition n’a pas de case pour “votre document n’a pas la bonne forme.”

Problème 2 : le problème de l’appel d’offres

Les RFP rassemblent des propositions. Les propositions sont comparées. La proposition qualifiée la moins chère l’emporte généralement, parfois ajustée par des pondérations d’évaluation que l’acheteur a définies à l’avance.

Ça marche pour du travail commodity. Si vous avez besoin de dix mille vis usinées à la norme ISO, la proposition qualifiée la moins chère est la bonne réponse, parce que le travail est réellement identique d’un vendor à l’autre. Le logiciel custom, c’est l’inverse. Le travail n’est pas identique. Le studio qui pose cinq questions tranchantes sur le problème et chiffre plus haut fait quelque chose que le moins cher ne fait pas, mais ni le RFP ni le format de l’offre ne captent cette différence.

Pire : le format sélectionne contre les studios avec lesquels vous voudriez réellement travailler. Les bons soit ne prennent pas la peine de répondre (ils préfèrent 30 minutes de conversation à trois jours de formulaire), soit gonflent le périmètre pour se protéger du drift inévitable, ce qui fait paraître leur offre chère. Les studios qui répondent vite avec des chiffres bas font l’une de trois choses : sous-estimer par optimisme pour décrocher le deal, prévoir de rentabiliser par avenants, ou se servir du build comme formation pour leur équipe junior. Le mécanisme sélectionne les mauvais partners.

Problème 3 : le problème de relation

Le RFP cadre l’engagement comme vendor et acheteur. Le vendor livre ; l’acheteur accepte ou rejette. Le contrat énumère les pénalités sur les jalons manqués. Le travail est opaque entre les checkpoints. L’acheteur n’a de visibilité qu’aux portes que le document a définies dès le départ.

Le logiciel custom a besoin de la forme inverse : visibilité hebdomadaire, itération rapide, décisions partagées sur des arbitrages que le fondateur ne pouvait pas anticiper la semaine zéro. Un studio qui est un vrai partner dit “il faut revoir le jalon trois à la lumière de ce qu’on a appris au deux.” Un vendor sous contrat dérivé d’un RFP dit “le jalon trois est dans le périmètre ; si vous voulez changer, voici l’avenant.” Le même studio fait l’une ou l’autre chose selon le contrat en dessous. Le RFP produit presque toujours la deuxième forme.

C’est pour ça que source code escrow, les clauses de lock-in et les provisions de sortie élaborées reviennent si souvent dans les contrats d’agence : ce sont les mécanismes de protection qu’une relation de vendor exige. Quand la relation est un vrai partenariat, la plupart sont inutiles.

Ce qu’il faut envoyer à la place : le brief de partenariat en cinq paragraphes

Remplacez le RFP par un document d’une page. Cinq paragraphes courts. Envoyez-le à deux ou trois studios que vous avez déjà mis en shortlist par référence, pas à cinq que vous avez trouvés sur Google.

Paragraphe 1. Le problème business en langage clair. Qu’est-ce que votre client vous paie pour résoudre ? Deux ou trois phrases, sans jargon. “Des courtiers indépendants en assurance à São Paulo passent 6 heures par police à rapprocher les relevés de commission de 14 assureurs. On leur facture un abonnement pour le faire en 10 minutes.” Plus utile que 40 exigences. Le studio apprend plus de ce paragraphe que de toute la section exigences d’un template de RFP.

Paragraphe 2. La première chose que vous lanceriez. Quelle est la plus petite version du système qui fait qu’un client payant l’utilise pour de vrai ? Pas le MVP au sens marketing, la première version que vous seriez fier de mettre devant un client payant. Voir notre article sur comment briefer un développeur pour startup pour le cadrage. Un paragraphe, trois ou quatre capacités centrales. Si vous n’arrivez pas encore à écrire ce paragraphe, le travail de discovery n’est pas terminé.

Paragraphe 3. Votre fourchette de budget. Un vrai chiffre, pas un plancher d’ancrage bas. “On a alloué entre 80 000 et 120 000 dollars pour le premier build.” Ou : “On a 60 000 dollars et on a besoin de savoir ce qu’on peut livrer avec ça.” Cacher le chiffre ne vous donne pas un meilleur prix ; ça vous donne des propositions calibrées sur le mauvais cadrage. Si vous ne connaissez pas la bonne fourchette, notre article sur le forfait vs. la régie couvre les questions structurelles.

Paragraphe 4. Votre calendrier et ce qui le contraint. “On a besoin de la v1 en production au 30 août parce que le pilote de notre premier client enterprise commence le 1er septembre.” La contrainte est la vraie information. Un calendrier sorti de nulle part (“on aimerait lancer au Q4”) ne dit rien au studio sur les arbitrages que vous êtes prêt à faire.

Paragraphe 5. Trois questions auxquelles vous voulez que le studio réponde par écrit. Pas “parlez-moi de votre société.” Des choses comme : Vous avez déjà construit quelque chose de similaire pour une société à une étape comparable ? Qui spécifiquement serait sur ce projet, par nom, et quel est son background ? Quelle est la première chose avec laquelle vous seriez en désaccord dans ce brief ? La troisième question sépare les partners des vendors plus vite que n’importe quel autre stimulus.

Un studio qui ne peut pas ou ne veut pas répondre à ce document en 48 heures n’est pas un fit. Un studio qui répond avec trois questions tranchantes à lui est exactement celui avec qui vous voulez continuer à parler.

Quand un RFP est effectivement le bon choix

Trois situations étroites, pour la plupart en dehors de l’achat de logiciel custom en phase amont.

Acheter du logiciel packagé. Vous choisissez un CRM, un ERP, une customer data platform, un HRIS. Le périmètre est défini par le produit lui-même. Les vendors sont de vraies cibles d’achat avec des équipes commerciales qui répondent aux RFP comme pratique standard. Le RFP fonctionne.

Secteurs régulés avec des règles d’achat. Réseaux de santé, institutions financières au-delà d’une certaine taille, acheteurs proches du public. Votre équipe contrats vous dira que le RFP est obligatoire et il n’y a pas d’argument valable contre. Utilisez l’instrument qui correspond à l’environnement de politique. Comprenez seulement que c’est la politique qui pousse le document, pas la nature du travail.

Travail réellement commodity avec un spec fini. Vous avez déjà construit la v1, le système est en production, et vous avez besoin d’un périmètre connu de fonctionnalités supplémentaires qui n’exige pas de discovery en format partenariat. Le RFP est raisonnable ici parce que le travail est effectivement devenu commodity. La plupart des fondateurs ne sont pas dans cet état et ne devraient pas faire semblant de l’être.

Si vous n’êtes pas dans l’un de ces trois cas, le brief de partenariat est le bon document.

Ce qu’il faut demander dans la première conversation qu’aucun RFP n’extraira

Le brief en cinq paragraphes est le filtre. La première conversation de 30 minutes est là où la sélection réelle se joue. Quatre questions qu’aucun document d’achats ne fera ressortir :

1. “Racontez-moi le dernier projet que vous avez refusé.” Les studios qui n’ont jamais dit non à un client disent oui à tout. C’est le pire signal. Les studios qui en valent la peine peuvent nommer l’engagement qu’ils ont refusé et expliquer pourquoi.

2. “Avec qui de votre équipe je parlerai en semaine 4 du projet ?” Si la réponse est le fondateur ou le commercial, l’équipe que vous avez vue au pitch n’est pas l’équipe qui construit. Le nom d’un ingénieur senior précis est la réponse que vous voulez.

3. “Qu’est-ce qui ne va pas dans mon brief selon vous ?” Un studio qui dit “rien, c’est parfait” vend. Un studio qui pointe le paragraphe 2 et dit “la première chose que vous lanceriez n’est pas celle que vous croyez” fait le travail à l’intérieur de la conversation.

4. “Quel est le plus petit engagement par lequel on pourrait commencer ?” Les vrais partners proposent un sprint de scoping ou de discovery de deux à quatre semaines avant de chiffrer le build complet. Les studios qui chiffrent 180 000 dollars au premier appel devinent.

Vous n’obtiendrez pas ces réponses d’une réponse de RFP écrite, aussi élaborée que soit la grille d’évaluation.

FAQ

Qu’est-ce qu’un RFP en développement logiciel ? Un Request for Proposal est un document formel d’achats que l’acheteur envoie aux vendors en décrivant ce qu’il veut construit, les contraintes, et comment les propositions seront évaluées. L’instrument vient des achats IT en grande entreprise et dans le public, où la sélection standardisée du vendor est obligatoire. Il fonctionne bien pour l’achat de logiciel packagé et les achats régulés, et mal pour le logiciel custom en phase amont où le périmètre est encore émergent. L’entrée Wikipedia sur Request for proposal couvre la définition formelle et l’histoire.

Faut-il envoyer un RFP à plusieurs studios de logiciel ? Pour un build custom en pre-seed ou seed, non. Envoyez un brief de partenariat d’une page à deux ou trois studios que vous avez déjà mis en shortlist par référence. Le pattern RFP-à-cinq-studios sélectionne les studios qui gagnent en gonflant les offres, pas par le craft.

Quelle est la différence entre un RFP et un SOW en développement logiciel ? Un RFP est un document d’achats utilisé avant la sélection du vendor : vous l’envoyez à plusieurs vendors, vous recueillez des offres et vous en choisissez un. Un Statement of Work est un document contractuel signé avec le vendor choisi : il définit périmètre, livrables, calendrier et prix de l’engagement réel. Beaucoup de fondateurs les confondent parce que les templates en ligne les mélangent. Le RFP vient en premier si vous en utilisez un ; le SOW vient toujours après la sélection.

Puis-je utiliser un template de RFP trouvé en ligne ? Vous pouvez. La plupart sont écrits pour des achats IT corporate et vont sur-spécifier votre projet d’un ordre de grandeur. Si vous décidez que le RFP reste le bon instrument pour votre situation, videz la section des exigences et remplacez-la par un énoncé du problème et un paragraphe de la-première-chose-à-livrer. Mieux encore : oubliez le template et envoyez le brief en cinq paragraphes.

Et si un studio me demande d’envoyer un RFP ? Quelques studios préfèrent le processus structuré de réponse parce que ça leur permet de router la proposition dans leur pipeline interne. C’est une préférence légitime. Envoyez le brief de partenariat d’abord et laissez-les le traduire dans l’artefact interne dont ils ont besoin. S’ils insistent pour que le brief soit en forme de RFP avant tout engagement, c’est un petit signal sur la manière dont l’engagement se passera. Lourd en processus, en forme de vendor, lent à itérer. Lisez-le en conséquence.

Quelle longueur doit faire un RFP de développement logiciel ? Si vous décidez d’en envoyer un, deux pages. Le brief en cinq paragraphes au format ci-dessus, plus une demi-page de critères d’évaluation. Au-delà, ça vient du template et ne fait pas de travail utile. Les RFP de grade achats font 20 à 40 pages parce qu’ils doivent passer la revue politique et juridique. Rien de tout ça ne s’applique à votre build.

L’instrument compte parce qu’il donne sa forme à la conversation. Le RFP de développement logiciel a été construit pour un type d’achat précis ; quasi rien dedans ne correspond à l’achat qu’un fondateur non technique fait en pre-seed. Envoyez le document qui correspond au travail, pas celui qui paraît le plus professionnel vu de l’extérieur.