Appel d'offres logiciel (RFP) : comment le préparer

Comment préparer un appel d'offres (RFP) de développement logiciel ? En décrivant clairement le problème à résoudre, le périmètre, les contraintes et les critères de choix — pas en dictant une solution technique. Un bon RFP (Request for Proposal) n'est pas un cahier des charges figé de 80 pages : c'est un document qui donne aux prestataires assez de contexte pour proposer et assez de structure pour que vous puissiez les comparer honnêtement. Ce guide explique quoi y mettre, quand un RFP est utile (et quand il ne l'est pas), et fournit une trame simple à adapter.

En résumé : un RFP efficace décrit le pourquoi et le quoi (objectifs, périmètre, contraintes) plus que le comment (que vous laissez au prestataire proposer). Il rend les offres comparables en imposant une structure de réponse commune, et il protège les deux parties en explicitant budget, calendrier et critères d'évaluation. Ce guide ne fournit aucun chiffre : les fourchettes de budget et de délai dépendent de votre périmètre — voyez nos guides dédiés au coût et au ROI.

Qu'est-ce qu'un RFP ?

Un RFP (appel d'offres) est un document par lequel vous décrivez un besoin et invitez des prestataires à proposer une approche, un plan et un prix. Il se distingue d'un simple devis par sa structure : il pose les mêmes questions à tous les candidats, ce qui rend les réponses comparables. Il se distingue d'un cahier des charges détaillé par son ouverture : il décrit le problème et laisse une marge à l'expertise du prestataire, au lieu de sur-spécifier une solution que vous n'avez peut-être pas encore validée.

Quand utiliser un RFP

• Le projet est suffisamment défini pour être décrit, mais assez ouvert pour bénéficier de propositions.
• Vous comparez plusieurs prestataires et voulez une base d'évaluation commune.
• L'enjeu justifie la rigueur : budget conséquent, gouvernance, parties prenantes multiples.
• Vous devez documenter le choix (procurement, conformité interne).

Quand ne PAS en utiliser

Un RFP a un coût — pour vous comme pour les répondants. Il est disproportionné quand le besoin est petit ou exploratoire, quand vous ne savez pas encore ce que vous voulez (un diagnostic ou un atelier de cadrage sert mieux qu'un RFP prématuré), ou quand vous avez déjà un partenaire de confiance pour un périmètre bien connu. Forcer un RFP là où une conversation suffirait ralentit tout le monde sans améliorer la décision. Le RFP est un outil de comparaison structurée, pas un passage obligé.

Ce que tout RFP devrait contenir

Un RFP lisible tient en quelques sections claires plutôt qu'en un pavé exhaustif :

• Contexte et objectifs — qui vous êtes, le problème à résoudre, le résultat attendu.
• Périmètre — ce qui est inclus, ce qui ne l'est pas, les systèmes à intégrer.
• Exigences — fonctionnelles, techniques, de sécurité (détaillées plus bas).
• Contraintes — existant, réglementation, délais incontournables.
• Format de réponse attendu — pour rendre les offres comparables.
• Critères d'évaluation et calendrier — comment et quand vous déciderez.

Les exigences fonctionnelles

Décrivez ce que le logiciel doit faire, du point de vue de l'utilisateur : parcours, rôles, règles métier, cas particuliers. Exprimez-les en résultats attendus (« un gestionnaire doit pouvoir valider une demande en un clic ») plutôt qu'en solutions imposées. Distinguez le indispensable du souhaitable : cette hiérarchisation aide les prestataires à proposer un périmètre réaliste et vous à arbitrer. Selon la nature du produit — application web, application mobile, logiciel métier ou SaaS — les exigences fonctionnelles n'ont pas la même forme.

Les exigences techniques

Précisez les contraintes techniques réelles, sans sur-spécifier : systèmes existants à intégrer, volumes attendus, exigences de performance et de disponibilité, préférences d'hébergement, besoins de données et de reporting, et le cas échéant d'IA. Évitez le piège de dicter la stack : laissez le prestataire proposer l'architecture et justifiez vos contraintes plutôt que de les imposer. Un bon répondant expliquera ses choix — c'est un signal de maîtrise.

Les exigences de sécurité

Rendez explicites vos attentes en matière de sécurité et de protection des données : authentification, gestion des accès, chiffrement, journalisation, sauvegardes, et le cadre légal applicable (nLPD suisse, RGPD européen). Précisez qui est responsable de quoi — le prestataire livre et documente la couche technique, votre conformité réglementaire reste la vôtre. Dans les secteurs sensibles comme la finance ou la santé, ces exigences pèsent lourd dans l'évaluation et méritent une section dédiée.

Les considérations de budget

Faut-il annoncer un budget dans un RFP ? Souvent oui — au moins une fourchette — car cela évite de recevoir des offres hors de portée et permet aux prestataires de calibrer leur proposition. Demandez un chiffrage sur le coût total (construction, maintenance, hébergement, évolutions), pas seulement la V1. Ce guide ne donne aucun montant : les fourchettes réelles dépendent de votre périmètre, et la méthode pour les établir est détaillée dans notre guide du coût d'un projet logiciel ; la façon d'en évaluer le retour, dans le guide du ROI.

Les considérations de calendrier

Indiquez les échéances qui comptent vraiment — une contrainte réglementaire, un événement, une saison — et distinguez-les des dates « confort ». Demandez aux prestataires de proposer un calendrier par incréments testables plutôt qu'une seule date de livraison lointaine ; c'est un meilleur indicateur de maîtrise et cela réduit le risque. Méfiez-vous des engagements de délai donnés sans avoir vu le périmètre en détail : ce guide ne cite aucune durée « type », car elle dépend du projet.

Les critères d'évaluation des prestataires

Annoncez à l'avance comment vous déciderez — et pondérez. Au-delà du prix, évaluez la solidité technique, la maîtrise produit, le processus de livraison, la communication, la sécurité, et la propriété (code, dépôts et comptes à votre nom). La grille complète d'évaluation est dans notre guide du choix d'un partenaire. Un critère souvent oublié mais décisif : le prestataire vous déconseille-t-il ce qui n'a pas de sens ? C'est un signe de partenariat, pas de docilité commerciale.

Les erreurs classiques

• Sur-spécifier la solution — dicter la stack prive vous de l'expertise que vous êtes venu chercher.
• Cacher le budget — reçoit des offres non calibrées et fait perdre du temps à tous.
• Critères d'évaluation flous ou absents — la décision devient subjective et contestable.
• Comparer des offres à périmètres différents — sans format de réponse commun, la comparaison est faussée.
• Oublier la maintenance et la propriété — voir le build vs buy et le ERP vs SaaS pour cadrer la décision sous-jacente.

Une trame de RFP simple

Une structure légère suffit pour la plupart des projets. Adaptez-la à votre contexte :

La checklist de décision

• Ai-je vraiment besoin d'un RFP, ou un cadrage suffirait-il ?
• Ai-je décrit le problème plutôt que dicté la solution ?
• Mes exigences distinguent-elles l'indispensable du souhaitable ?
• Mon budget et mon calendrier sont-ils explicites et réalistes ?
• Mes critères d'évaluation sont-ils annoncés et pondérés ?
• Le format de réponse rend-il les offres comparables ?
• Ai-je exigé la propriété du code et des données ?

La preuve sectorielle du répondant se vérifie sur des réalisations concrètes — Omnia, Watchonista, FlySpa, E. Gutzwiller — et sur la compréhension de votre secteur, qu'il s'agisse de l'industrie, de l'immobilier, du retail ou du luxe et des médias.

Questions fréquentes

RFP, cahier des charges, devis : quelle différence ?

Le RFP décrit un besoin et invite à proposer, avec un format de réponse commun pour comparer. Le cahier des charges spécifie une solution en détail. Le devis chiffre une prestation définie. Le RFP se situe en amont : il sert à choisir un partenaire et une approche, pas à figer chaque écran.

Faut-il indiquer le budget dans un RFP ?

Le plus souvent oui, au moins une fourchette : cela évite les offres hors de portée et aide les prestataires à calibrer. Cacher le budget fait perdre du temps à tout le monde. Demandez un chiffrage en coût total, pas seulement pour la V1.

Quelle longueur pour un bon RFP ?

Assez pour décrire le problème et les contraintes, pas plus. Un RFP concis et bien structuré attire de meilleures réponses qu'un pavé exhaustif. Huit sections claires suffisent à la plupart des projets.

Faut-il imposer la technologie dans un RFP ?

Rarement. Décrivez vos contraintes (systèmes existants, performance, sécurité) et laissez le prestataire proposer l'architecture. Dicter la stack vous prive de l'expertise que vous cherchez ; un bon répondant justifie ses choix.

Combien de prestataires inviter ?

Assez pour comparer, pas trop pour submerger votre équipe d'évaluation : une short-list ciblée vaut mieux qu'un envoi massif. Au-delà de quelques candidats sérieux, l'évaluation se dilue.

Comment rendre les offres comparables ?

En imposant un format de réponse commun et des critères d'évaluation pondérés annoncés à l'avance. Sans cette structure, vous comparez des propositions à périmètres et présentations différents — une comparaison faussée.

Que faire si aucune offre ne convient ?

C'est une issue légitime : mieux vaut un RFP infructueux qu'un mauvais choix. Souvent, cela révèle un besoin mal cadré — un diagnostic ou un atelier de cadrage permet de reformuler avant de relancer.

Vous préparez un RFP ou hésitez à en lancer un ? Parlons-en 30 minutes ou demandez un diagnostic en 48 h — nous vous aidons à cadrer le besoin avant de consulter, sans engagement.