Liste de contrôle RFP pour le développement logiciel

Une consultation RFP pour un projet logiciel doit énoncer le problème, les exigences fonctionnelles et non fonctionnelles, les besoins de sécurité et de données, les conditions commerciales et la méthode de notation avant toute réponse d'un prestataire. Notez les critères pondérés au lieu de discuter après coup, vérifiez les références plutôt que de croire les études de cas, et menez un court pilote payant avant de vous engager sur un budget.

Que doit contenir une consultation RFP logicielle ?

Le document existe pour rendre les réponses comparables. Un prestataire ne peut répondre qu'à ce qui est écrit ; une consultation qui décrit une vision et demande un prix invite à des propositions toutes excellentes et aucune évaluable les unes par rapport aux autres. Le contenu fonctionnel, les contraintes et la règle de notation doivent être fixés avant la première réponse, sinon l'évaluation devient une négociation sur les critères.

Il y a aussi un point d'ordre qui fait gagner des mois : la consultation n'est pas l'endroit où l'on découvre ce dont on a besoin. Les exigences sortent d'un travail interne — les responsables de processus décrivant comment l'activité tourne réellement, la finance énonçant ce qui doit se rapprocher, les gens qui utiliseront le système au quotidien disant où se situe la douleur actuelle. Ce travail est lent et politique, et il se fait avant qu'aucun prestataire ne soit mêlé. Les équipes qui le déléguent au premier prestataire arrivé obtiennent des exigences rédigées dans le langage produit de ce prestataire, ce qui fait ensuite paraître toutes les autres propositions mal adaptées — non parce qu'elles le sont, mais parce que la référence a été écrite autour d'un des soumissionnaires.

Une distinction de plus à conserver, entre trois documents souvent confondus. Un RFI interroge le marché sur ce qui existe ; il est court, il précède les exigences, et il n'engage personne. Une consultation RFP demande une proposition contre des exigences définies et une méthode d'évaluation annoncée. Un RFQ demande un prix contre un périmètre défini. Mener un RFQ avant que le périmètre existe est la façon la plus courante de comparer trois chiffres qui signifient trois choses différentes.

Cinq choses qu'une consultation complète fait et qu'une incomplète ne fait pas :

• Elle définit le problème, pas la solution. « Réduire le temps d'élaboration du rapport mensuel consolidé de plusieurs jours à un nombre défini d'heures » est un énoncé de problème ; « construisez-nous un entrepôt de données » est une hypothèse de solution qui ne le résoudra peut-être pas.


• Elle sépare les exigences des préférences. Les indispensables qui décident du passage ou du rejet, les importants qui décident du rang, et les agréables qui ne décident de rien. Les prestataires ne répondent sérieusement que si cette distinction est visible.


• Elle nomme les contraintes. Systèmes existants à intégrer, données à migrer, obligations d'audit et de conservation, fenêtre de mise en service, qui valide.


• Elle annonce la méthode d'évaluation à l'avance. Critères pondérés, qui évalue, quelles preuves sont exigées, et quand les prestataires écartés reçoivent un récapitulatif de leurs notes.


• Elle fixe les dates du processus. Date limite de questions, fenêtre de clarification, date limite de dépôt, période d'évaluation, date de décision. Un processus sans dates attire les prestataires qui sont déjà occupés.

Structure de la consultation RFP

Exigences fonctionnelles et non fonctionnelles du logiciel

Les exigences fonctionnelles décrivent ce que fait le système : quels processus, pour quels rôles, avec quels sorties. Les exigences non fonctionnelles décrivent la qualité avec laquelle il le fait, et ce sont celles qui manquent le plus souvent — puis imposées plus tard, cher, ou pas du tout.

Digne d'être énoncé explicitement dans la plupart des projets B2B :

• Performances. Temps de réponse sous une charge indiquée, pour les opérations qui comptent — saisie de commande, génération de rapports, clôture de fin de mois.


• Disponibilité. De quel temps de fonctionnement l'activité a-t-elle besoin, fenêtres de maintenance, et que se passe-t-il quand le système est hors service — une cible sans description des interruptions acceptables n'est pas une exigence.


• Reprise. RTO et RPO en termes simples : à quelle vitesse l'activité reprend après un incident, et combien de travail peut être perdu. Les deux chiffres appartiennent à l'évaluation, pas seulement au contrat.


• Piste d'audit. Qui a modifié quoi et quand, conservé combien de temps, récupérable par qui — surtout là où l'argent, le stock ou des données personnelles circulent.


• Accessibilité et ergonomie. Qui utilise le système, sur quels appareils, dans quelles langues ; un système que l'entrepôt ne peut pas exploiter n'est pas mis en œuvre, si bien qu'il se note.


• Intégration et données. Quels systèmes se connectent, dans quel sens circulent les données, et qui détient l'enregistrement maître de chaque entité.

Sécurité et conformité : les questions à poser

La sécurité se pose mieux en questions avec preuves exigées qu'en ligne oui/non. Celles qui méritent d'y figurer :

• ISO/IEC 27001 — le prestataire le détient-il, et que couvre le périmètre certifié ? Un certificat couvrant l'organisation commerciale mais pas les équipes de livraison vous renseigne sur un point précis.


• Développement sécurisé — où la sécurité se situe dans la conception, la revue de code et les tests ; si le traitement des dépendances et des vulnérabilités est routine.


• OWASP Top 10 — s'il fait partie de la revue du prestataire pour les composants exposés sur le web ; une question concrète et répondable.


• Contrôle d'accès — qui peut atteindre vos environnements et vos données, comment l'accès est accordé et révoqué, quels journaux existent.


• Obligations de protection des données — KVKK et RGPD là où ils s'appliquent ; qui est responsable, qui est sous-traitant, ce que dit l'accord de traitement sur les sous-traitants successifs et la notification de violations.

Conditions commerciales et SLA

Demandez la tarification dans une structure comparable : ce qui est inclus, ce qui est facturé à part, et comment les changements sont tarifés. Un chiffre seul sans périmètre derrière ne se compare pas à un autre chiffre seul ; la page des modèles de coût et de tarification explique les structures courantes et les questions que chacune soulève.

Les SLA méritent la même précision que les exigences. Un pourcentage de disponibilité n'a de sens qu'avec sa méthode de mesure, ses exclusions et son remède ; un temps de réponse n'a de sens qu'avec ses définitions de gravité et ses heures ouvrables. Demandez à chaque prestataire de définir les termes du SLA plutôt que d'accepter une page de pourcentages sans définitions.

Matrice de notation de l'évaluation

Un modèle copiable. Les pondérations ci-dessous sont un exemple — fixez les vôtres selon vos priorités et gardez le total à 100. Définissez ce que signifient 1, 3 et 5 avant que quiconque ne note, pas quand les disputes ont commencé.

Deux disciplines rendent cet exercice opérant. Notez indépendamment avant de discuter, pour que la première voix assurée ne fixe pas la salle. Et consignez une ligne de justification par note — les prestataires qui reçoivent un récapitulatif de notes avec motifs acceptent le résultat bien plus volontiers, et votre propre équipe peut le défendre six mois plus tard.

Une troisième discipline porte sur qui note. Le jury doit inclure les gens qui vivront avec le résultat — le responsable de processus, la personne responsable des données, quelqu'un de la sécurité ou de la finance quand ces fonctions existent —, pas seulement les achats. Les évaluations échouent en silence quand le jury note ce qu'il peut juger (la structure de la proposition, l'élégance de l'équipe commerciale) et repousse ce qu'il ne peut pas (si l'approche d'intégration convient réellement aux systèmes en place). Un technique ayant autorité pour dire « ça ne marchera pas avec ce qu'on fait tourner » prévient plus de coûts que n'importe quelle remise.

Les pondérations elles-mêmes méritent un avertissement de plus : elles sont une déclaration de priorités qui devient visible pour les prestataires. Si la sécurité pèse 5 % et le prix 30 %, les prestataires sérieux s'en apercevoiront, et votre propre équipe aussi quand le contrat sera signé. Une pondération mise à la hâte, pour remplir le tableau, est lue comme la vérité par tous ceux qui n'étaient pas dans la salle ; fixez-la une fois, avec les décideurs présents, et ne changez-la qu'avec la même formalité que celle qui l'a établie.

Vérification des références et pilote

Les études de cas sont du marketing ; les références sont des preuves. L'appel qui fonctionne est court et interroge sur ce qui s'est passé, pas sur ce qui a été livré : le projet est-il allé au bout, qu'est-ce qui a changé dans le périmètre, qui était réellement dans l'équipe, qu'auraient-ils fait autrement, et recommenceraient-ils le projet avec ce prestataire. Les réponses au passé et précises sont le signal.

Demandez une référence de projet qui ressemble au vôtre en taille et en complexité, pas l'œuvre la plus fière du prestataire — une mise en œuvre phare de deux fois votre budget n'apprend rien sur le comportement de l'équipe à votre échelle. Et vérifiez la référence vous-même : un contact que le prestataire briefe à l'avance est un témoignage, pas une référence ; l'appel utile est celui où le client apprend sur le moment ce que vous demandez.

Un court pilote payant teste ensuite la partie qu'aucune référence ne peut : comment cette équipe travaille avec vos gens quand les exigences sont incomplètes. Les règles de conception sont les mêmes qu'il vaut de poser pour tout pilote — vrai travail, critères de recette écrits, un changement en cours de route, et une règle de décision convenue à l'avance. La page d'externalisation traite la conception du pilote plus en détail.

Clauses contractuelles à vérifier

• Cession de propriété intellectuelle — droits sur le code, la documentation et les dérivés transférés à vous, dès la création, pas seulement au paiement final.
• Propriété des données — vos données restent les vôtres ; les droits du prestataire sont limités à ce qui est nécessaire pour livrer.
• Recette — ce que signifie la recette, qui la prononce, et le processus quand quelque chose l'échoue.
• Gestion des changements — comment les changements de périmètre sont demandés, tarifés et approuvés ; sans elle, chaque changement devient un litige.
• Sortie et transition — code source, accès, documentation et assistance à la fin ; comment la connaissance se transfère si le prestataire change.
• Dépôt de code (escrow) — là où la continuité d'activité dépend de composants détenus par le prestataire, ce qu'il advient si celui-ci ne peut poursuivre.
• Responsabilité — plafonds, exclusions et ce qui n'est pas assuré ; lisez-le avec la même attention que le prix.
• Résiliation — préavis, obligations après résiliation, et le processus de restitution ou de suppression des données.

Questions fréquentes

Faut-il envoyer un RFI ou une consultation RFP d'abord ?

Un RFI quand le marché ou le problème est flou — vous demandez ce qui existe et ce que cela coûte. Une consultation RFP quand les exigences et la méthode d'évaluation sont définies ; en envoyer une plus tôt ne fait que déplacer le travail d'exigences dans la proposition de chaque prestataire, avec ses mots et ses priorités.

Combien de prestataires faut-il inviter ?

Assez peu pour pouvoir lire chaque proposition correctement et appeler chaque référence. La plupart des évaluations perdent en qualité au-delà d'une petite poignée ; une présélection construite depuis un RFI, un appel de triage et un projet de référence similaire est en général plus utile qu'une longue liste de noms célèbres.

Comment fixer les pondérations ?

À partir de vos priorités, avant de voir toute proposition, et convenues entre les gens qui vivront avec le résultat. Un échec courant, c'est des pondérations égales partout, ce qui revient à dire que rien n'importe plus que rien d'autre ; si le prix ou le risque domine pour vous, les pondérations doivent le dire.

Faut-il noter le prix ?

Oui, mais comme un critère pondéré au périmètre figé, pas comme toute l'évaluation. Un prix noté sans périmètre derrière récompense le prestataire qui a supposé le moins de travail ; chiffrez d'abord vos exigences, puis comparez les totaux pour la même chose.

Comment note-t-on les réponses de sécurité ?

Sur les preuves, pas sur le ton. Trois niveaux fonctionnent : aucune position (1), politiques décrites (3), périmètre du certificat vérifié plus développement sécurisé décrit et preuves fournies (5). Là où un prestataire n'a aucun certificat, demandez quels contrôles équivalents existent par écrit — un non honnête avec des contrôles documentés se note mieux qu'un oui invérifiable.

Peut-on modifier les exigences après l'envoi de la RFP ?

Avant les dépôts, oui — avec le changement annoncé à tous. Après les dépôts, seulement par une clarification formelle que reçoivent tous les soumissionnaires ; modifier en silence les exigences pour un seul prestataire met fin à la comparabilité sur laquelle tout le processus reposait. Après le contrat, c'est à la gestion des changements qu'il appartient.

Sources et normes

• ISO — éditeur de l'ISO/IEC 27001 (management de la sécurité de l'information) ; vérifiez l'édition en vigueur et le périmètre d'un certificat avant de vous y fier.
• OWASP — éditeur de la liste Top 10 des risques de sécurité des applications web référencée sur cette page.
• Les principes de la matrice de notation suivent les modèles de consultation RFP publiés ; les pondérations affichées sont un exemple à éditer, pas une recommandation. Cette page est un guide d'achat, pas un avis juridique, et aucune certification ni audit n'est revendiqué pour WorldwideTradeX.

Pages associées

Développement logiciel · Externalisation informatique depuis la Türkiye · Modèles de coût et de tarification · Audit et conseil IT · Demander un devis