Appel d’offres logiciel : comment les studios le lisent, l’évaluent et l’établissent leur prix

Appel d’offres logiciel : comment les studios le lisent, l’évaluent et établissent leur prix

Un appel d’offres logiciel est lu par des personnes qui décident s’il vaut la peine de consacrer une semaine du temps d’ingénieurs seniors à une offre qu’elles ne remporteront peut-être pas. Dans les quinze premières minutes, un studio a généralement décidé s’il allait répondre, avec quel degré d’implication et en assumant quel niveau de risque tarifaire. Cet article examine cette décision du point de vue du prestataire, afin que vous puissiez envoyer un appel d’offres logiciel qui vous permette d’obtenir de meilleures propositions et des tarifs plus justes de la part des entreprises que vous souhaitez réellement retenir.

Il ne s’agit pas d’un guide pour savoir comment rédiger un appel d’offres. Nous couvrons déjà la structure, les modèles, la notation et la sécurité dans notre guide sur les appels d’offres de développement logiciel. Nous nous intéressons ici à ce qui se passe après avoir cliqué sur Envoyer.

Points clés à retenir

• Les studios trient rapidement les appels d’offres logiciels. Un périmètre flou, l’absence d’indication budgétaire et l’impossibilité d’échanger avec les décideurs sont les raisons habituelles pour lesquelles les entreprises les plus solides déclinent.
• Des exigences vagues ne produisent pas d’offres moins chères. Elles produisent des offres majorées, car le prestataire doit chiffrer le risque lié à ce qu’il ne peut pas voir.
• Les critères d’évaluation indiquent aux prestataires quoi rédiger. Si vous accordez du poids à la collaboration et à l’approche, vous recevrez des propositions portant sur la collaboration et l’approche.
• Une fourchette budgétaire, une période de questions-réponses et un responsable désigné contribuent davantage à la qualité des propositions que toute page supplémentaire d’exigences.
• Une proposition fournisseur peu étoffée est souvent un signal concernant votre appel d’offres, et pas seulement concernant le prestataire.

Table des matières

• À quoi doit servir un appel d’offres logiciel
• À quoi ressemble un appel d’offres logiciel du point de vue du prestataire
• Comment les studios évaluent les exigences
• Comment les critères d’évaluation influencent les propositions que vous recevez
• Comment les studios chiffrent un appel d’offres logiciel
• Les signaux d’alerte que les prestataires repèrent dans un appel d’offres
• Ce que les propositions solides révèlent sur votre appel d’offres
• Comment lire équitablement les réponses des prestataires
• Avez-vous réellement besoin d’un appel d’offres logiciel ?
• Notre approche d’un appel d’offres logiciel chez Ridiculous Engineering
• Envoyez un appel d’offres logiciel qui mérite une réponse
• FAQ
• Sources

À quoi doit servir un appel d’offres logiciel

Un appel d’offres demande à plusieurs prestataires de soumettre des offres formelles répondant aux exigences que vous définissez. Selon la présentation de TechTarget sur les appels d’offres, il est surtout utile pour les projets complexes comportant des éléments variés. Cette définition décrit l’objectif de l’acheteur. Celui du prestataire est différent : déterminer s’il s’agit d’un projet qui mérite une offre et, dans l’affirmative, ce qu’il coûtera réellement à réaliser.

Ces deux objectifs se rencontrent dans le document. Un bon appel d’offres facilite les deux. Un mauvais oblige le prestataire à deviner, et les suppositions sont intégrées au prix.

À quoi ressemble un appel d’offres logiciel du point de vue du prestataire

Imaginez la personne qui le reçoit : un responsable principal, un responsable de l’ingénierie ou un architecte de solutions qui gère également des missions clients en cours. Elle ne le lit pas pour le plaisir. Elle effectue un examen rapide, en se posant toujours les mêmes questions.

Les questions du premier examen

1. Y a-t-il un problème réel et un responsable clairement désigné ? Un sponsor métier clairement nommé et un résultat attendu explicitement formulé indiquent que le projet aboutira. Un document qui ne comporte ni l’un ni l’autre laisse plutôt penser à une démarche exploratoire.
2. Le budget est-il à la hauteur du périmètre ? Peu d’acheteurs publient un montant, mais une fourchette ou un plafond permet au prestataire d’indiquer rapidement si le projet correspond à ses capacités. Sans cela, le prestataire abandonne l’appel d’offres ou chiffre une version très ambitieuse du projet par prudence.
3. Le RFP correspond-il à un véritable processus de sélection ? Les studios savent souvent reconnaître qu’un prestataire a déjà été choisi et que le RFP n’est qu’une formalité administrative liée aux achats. Ils ont tendance à décliner ce type de demande, car rédiger une proposition sérieuse coûte cher.
4. Pouvons-nous échanger avec quelqu’un ? Une période de questions-réponses et un interlocuteur capable de répondre aux questions produit constituent des signaux très positifs.
5. Le calendrier est-il réaliste ? Un délai de réponse de quelques jours pour un projet complexe indique aux prestataires que l’acheteur accorde davantage d’importance à la rapidité des formalités qu’à la qualité des réponses.

Répondre à un appel d’offres demande un véritable effort. Les hypothèses de cadrage, les esquisses d’architecture, le dimensionnement de l’équipe et le modèle tarifaire nécessitent tous l’attention de profils expérimentés. Les entreprises très sollicitées ne consacrent cet effort qu’aux projets dont les chances sont raisonnables.

Pourquoi est-ce important pour vous ?

Les entreprises les plus susceptibles de décliner un RFP vague sont souvent celles qui disposent du plus grand nombre d’options. Si vous voulez obtenir une réponse à un RFP logiciel de la part d’une équipe au solide bilan, le document doit respecter son temps. Cela signifie moins de sections passe-partout et davantage d’informations susceptibles de modifier le prix.

Comment les studios évaluent les exigences

Les exigences sont ce qui retient le plus l’attention des prestataires lors de leur lecture, car c’est là que se cachent les coûts.

Le niveau de détail est utile, mais pas n’importe lequel

Des exigences détaillées permettent d’obtenir des réponses comparables. Un RFP logiciel peut utilement inclure les exigences, les informations sur le prestataire, les références, les licences et les coûts du projet, comme le décrit le guide du Project Management Institute consacré au processus de RFP Pour un studio, les détails utiles sont ceux qui modifient l’effort à fournir :

• Le nombre de rôles utilisateurs et les actions possibles pour chacun
• Les systèmes à intégrer et l’existence éventuelle d’API documentées
• L’emplacement actuel des données et leur niveau de qualité
• Les obligations applicables en matière de conformité ou d’accessibilité
• Les personnes qui exploiteront le logiciel après son lancement

Ce qui est moins utile, c’est une liste de fonctionnalités de 200 lignes sans aucune priorité. Classer les éléments comme indispensables ou souhaitables, idéalement sous forme de récits utilisateurs assortis de critères d’acceptation, permet au prestataire de distinguer le développement essentiel de la liste de souhaits. En l’absence de priorités, un prestataire rigoureux chiffre tout comme obligatoire.

Prescrire la solution plutôt que décrire le problème

Certains RFP imposent l’architecture, la pile technologique et les écrans. D’autres décrivent le problème et les indicateurs de réussite. Les recommandations de PublicCode.net sur la rédaction des RFP préconisent des critères axés sur le problème, qui laissent aux prestataires le choix du quoi et du comment, ouvrant ainsi la voie à de nouvelles approches.

Du point de vue du prestataire, la différence est réelle. Si votre RFP prescrit une solution, vous obtiendrez de la conformité, pas du discernement. Chaque prestataire approuvera votre conception et les propositions se ressembleront. Si vous décrivez le problème, vous pourrez voir comment chaque équipe raisonne, ce qui est l’information dont vous avez besoin pour sélectionner un prestataire logiciel.

L’exception concerne une contrainte stricte. Si vous devez fonctionner sur un cloud précis, vous intégrer à un ERP précis ou respecter une norme précise, dites-le clairement. Les contraintes sont utiles. Les préférences déguisées en contraintes ne le sont pas.

Comment les critères d’évaluation façonnent les propositions que vous recevez

Les prestataires lisent votre grille de notation comme un cahier des charges rédactionnel. Ils mettront l’accent sur tout ce qui rapporte des points.

Les grilles d’évaluation publiées montrent l’ampleur des différences possibles. Une cour supérieure de Californie a noté les propositions sur une échelle de 100 points couvrant l’expérience, le coût, l’assistance, la collaboration, la disponibilité sur site, la présence d’une équipe dédiée et l’acceptation des conditions. Une association régionale d’observation des océans, dans son RFP relatif à la gestion des données, a attribué 30 % chacun aux qualifications techniques et à l’approche opérationnelle accompagnée d’un plan de transition, et 10 % à la capacité de partenariat stratégique.

Aucune de ces deux approches n’est nécessairement la bonne pour vous. L’essentiel est ce qu’un prestataire en déduit. Dans le second exemple, il comprend que la manière dont il reprend et exploite le système compte autant que le code. Sa proposition consacrera ses pages à cet aspect.

Une matrice pondérée témoigne de la rigueur

Une matrice d’évaluation des exigences, qui note les réponses en fonction d’éléments pondérés indispensables, souhaités ou simplement appréciables, est un outil courant, et le Guide du PMI le décrit comme une comparaison transparente fondée sur un tableur. Lorsqu’un fournisseur en voit un dans le RFP, il comprend deux choses : l’acheteur a réfléchi à la manière de prendre sa décision, et celle-ci a moins de chances de se résumer au prix le plus bas.

Le problème de la pondération du prix

La pondération des coûts est le levier que les acheteurs évaluent le plus souvent mal. Si vous attribuez 60 % de la note au prix, vous recevrez des offres agressives de fournisseurs prêts à partir du principe que tout se déroulera sans difficulté, ainsi que des offres réfléchies de fournisseurs qui renonceront à soumissionner. Si vous la fixez à 20 ou 30 %, vous favoriserez des propositions qui expliquent honnêtement les risques. Aucun de ces extrêmes n’est nécessairement mauvais, mais soyez délibéré. Votre pondération indique le type de fournisseur que vous recherchez.

Comment les studios établissent le prix d’un RFP logiciel

C’est l’aspect que les acheteurs voient le moins. Le prix d’une réponse à un RFP logiciel résulte rarement d’un calcul unique. Il s’agit d’une estimation à laquelle s’ajoute une marge de risque.

Étape 1 : Évaluer le volume de travail

L’équipe décompose le périmètre en composants, estime l’effort nécessaire pour chacun et tient compte de la conception, de l’ingénierie, des tests, de la gestion de projet et du déploiement. Chaque élément laissé flou par le RFP fait l’objet d’une hypothèse.

Étape 2 : Chiffrer les inconnues

Chaque ambiguïté devient soit une hypothèse explicite, soit une provision pour imprévus. Si le RFP indique « intégrer nos systèmes existants » sans en préciser aucun, le fournisseur doit déterminer s’il s’agit d’une API simple ou de cinq bases de données anciennes. Un fournisseur prudent part du scénario le plus complexe, ou inscrit l’hypothèse dans la proposition et chiffre un processus de gestion des changements en conséquence.

C’est pourquoi des exigences vagues ne permettent pas d’économiser de l’argent. L’incertitude n’est pas gratuite, et quelqu’un doit en assumer le coût. Le fournisseur l’intègre soit au prix, soit se protège dans le contrat.

Étape 3 : Choisir un modèle commercial

Le forfait, la facturation au temps et aux matériaux et les modèles par phases transfèrent chacun le risque à une partie différente. Un forfait appliqué à un périmètre flou fait peser le risque sur le fournisseur, qui l’intègre à son prix. La facturation au temps et aux matériaux le reporte sur l’acheteur, qui bénéficie de plus de souplesse mais de moins de certitude. De nombreux studios proposent une courte phase de cadrage payante, suivie d’une estimation de réalisation, car elle remplace les suppositions par des éléments concrets. Si votre RFP l’interdit, vous demandez aux fournisseurs de deviner.

Pour comprendre ce qui influence les montants du marché, consultez notre analyse du coût du développement logiciel sur mesure.

Étape 4 : Décider du niveau de compétitivité

Le fournisseur examine ensuite la concurrence. Une fourchette budgétaire est utile à ce stade : elle permet à un studio de proposer la meilleure version du projet compatible avec vos moyens, plutôt que la version idéale que vous ne pouvez pas vous permettre. Après réception des propositions, le processus se poursuit souvent par une présélection, des négociations tarifaires et techniques, des offres finales optimisées et une attribution fondée sur les critères annoncés, comme le souligne TechTarget. Les fournisseurs le savent. Certains prévoient une marge de négociation. D’autres soumettent leur véritable prix et s’y tiennent. Indiquer clairement si vous organiserez un tour d’offres finales optimisées permet à chacun de jouer selon les mêmes règles.

Signaux d’alerte dans un RFP que les fournisseurs remarquent

Voici les schémas qui incitent les studios expérimentés à décliner l’invitation ou à soumissionner avec prudence. La plupart sont faciles à corriger avant l’envoi.

Aucun de ces éléments n’est rédhibitoire à lui seul. Plusieurs réunis indiquent à un studio qu’il ferait mieux de consacrer son temps à autre chose.

Concernant les clauses contractuelles, les recommandations du PMI suggèrent que le service juridique ou l’administration des contrats fournisse les clauses types pour les instructions aux soumissionnaires, les conditions générales et la confidentialité. Faites-le rapidement. Des clauses qui apparaissent pour la première fois au stade du contrat vous coûtent de la confiance et du temps.

Ce que les propositions solides révèlent sur votre appel d’offres

Si les propositions des fournisseurs que vous recevez sont succinctes, génériques ou presque identiques, résistez à l’envie de rejeter d’abord la faute sur les fournisseurs. Vérifiez l’appel d’offres.

• Propositions génériques signifient généralement que l’appel d’offres ne fournissait aucun élément précis auquel répondre.
• Prix très différents signifient généralement que le périmètre était ambigu et que chaque fournisseur a formulé des hypothèses différentes. Demandez-leur d’énumérer leurs hypothèses et comparez-les avant de comparer les totaux.
• Peu de réponses signifient généralement qu’un problème de calendrier, de budget ou de conditions a été relevé par les entreprises sérieuses.
• Propositions qui reformulent vos exigences sans commentaire signifient que le fournisseur n’avait ni la possibilité ni la raison d’exercer son jugement.

Une réponse solide à un appel d’offres logiciel fait quelque chose de plus utile. Elle remet en question une hypothèse, propose un phasage, pose une question difficile sur une intégration ou signale qu’une exigence représente l’essentiel du coût. C’est ce type de proposition qu’il vaut la peine de trouver, et c’est le type de réponse auquel votre appel d’offres doit laisser de la place.

Comment lire équitablement les réponses des fournisseurs

Une fois les réponses reçues, le point de vue du fournisseur peut vous aider à les évaluer.

1. Comparez les hypothèses avant les totaux. Deux prix ne sont comparables que s’ils reposent sur le même périmètre.
2. Intéressez-vous aux personnes. Qui réalisera concrètement le travail, et participera-t-il aux questions-réponses ? Notre cadre pour choisir une entreprise de développement logiciel sur mesure approfondit les signaux liés à l’équipe et au processus.
3. Valorisez la transparence sur les risques. Un fournisseur qui signale ce qui pourrait mal tourner vous montre généralement l’expérience pour laquelle vous payez.
4. Demandez une séance de travail. Une heure d’échange en direct avec l’équipe chargée de la réalisation vous en apprendra davantage qu’une nouvelle série de questions écrites.
5. Considérez le prix le plus bas avec méfiance, et le plus élevé avec curiosité. Demandez à chacun de détailler ce qui est inclus et ce qui ne l’est pas.

Les acheteurs du secteur public doivent respecter des règles supplémentaires, présentées dans notre guide d’achat de logiciels pour le secteur public.

Avez-vous vraiment besoin d’un appel d’offres logiciel ?

Parfois, la réponse honnête est non. Un appel d’offres formel convient aux achats complexes et à forts enjeux, lorsque plusieurs fournisseurs qualifiés pourraient réussir et que vous avez besoin d’un dossier défendable et comparable. Il convient moins lorsque vous cherchez encore à déterminer quoi construire, lorsque le budget est limité ou lorsque vous faites déjà confiance à un partenaire. Dans ces cas, une courte mission de découverte ou un échange avec deux ou trois entreprises présélectionnées vous permet souvent de parvenir plus rapidement à une meilleure réponse.

Il vaut également la peine de remettre le principe en question. Tout système personnalisé implique une responsabilité à long terme en matière d’hébergement, de sécurité et de mises à jour ; assurez-vous donc que le développement sur mesure est la bonne solution avant d’entamer le processus. Notre article sur les logiciels open source et propriétaires peut vous aider à répondre à cette question.

Notre approche d’un appel d’offres logiciel chez Ridiculous Engineering

Nous lisons les appels d’offres comme le décrit cet article et nous nous efforçons d’y répondre de manière pertinente. Nous recherchons le résultat attendu, le responsable et les contraintes, et nous vous dirons clairement lorsqu’une exigence augmente les coûts ou lorsqu’une première phase plus réduite vous servirait mieux. Les clients travaillent directement avec des ingénieurs expérimentés, de la découverte jusqu’aux améliorations à long terme.

Si vous préparez l’envoi d’un appel d’offres logiciel, ou si vous avez reçu des propositions et souhaitez obtenir un second avis, notre équipe de développement de logiciels sur mesure peut vous aider, et notre accompagnement en conseil et en réalisation de logiciels comprend l’examen, côté fournisseur, du périmètre et des estimations. Les logiciels sur mesure font l’objet d’un cadrage individuel, avec un tarif communiqué sur demande. Les projets de sites web simples commencent à 3 000 USD, et le prix final dépend du périmètre et de la complexité.

Envoyez un appel d’offres logiciel auquel il vaut la peine de répondre

Un appel d’offres logiciel est plus efficace lorsqu’il est rédigé pour les deux personnes qui le liront : l’évaluateur qui le note et l’ingénieur qui en établit le prix. Présentez aux fournisseurs un problème réel, une indication budgétaire, vos priorités, un moyen de poser des questions et des critères correspondant à ce qui compte pour vous. Vous recevrez moins de propositions, mais de meilleure qualité, avec des prix qui reflètent le travail plutôt que les inconnues.

FAQ

Pourquoi de bons studios de logiciels refusent-ils de répondre à un appel d’offres ?

Le plus souvent, parce que le coût d’une réponse sérieuse dépasse les chances de remporter le marché. L’absence d’informations budgétaires, l’impossibilité de poser des questions, un délai très court ou la suspicion qu’un fournisseur a déjà été présélectionné sont les déclencheurs les plus courants. Corriger ces points dans votre document permet aux entreprises solides de revenir dans la course.

Devrais-je inclure mon budget dans un appel d’offres logiciel ?

Il vaut généralement la peine d’indiquer une fourchette ou un plafond. Les fournisseurs peuvent ainsi proposer la meilleure solution dans vos moyens au lieu de deviner, et les propositions sont plus faciles à comparer. Si vous ne pouvez pas communiquer de montant, indiquez au moins si le projet est financé et comment le budget a été établi.

Pourquoi les prix indiqués dans les propositions de mes fournisseurs sont-ils si différents ?

Le plus souvent, parce que chaque fournisseur a formulé des hypothèses différentes concernant un périmètre imprécis, les intégrations ou les responsabilités après le lancement. Demandez à chaque soumissionnaire d’énumérer ses hypothèses et exclusions, puis comparez les totaux sur une base équivalente.

Qu’est-ce qu’une offre définitive et finale ?

Il s’agit d’une étape suivant l’évaluation initiale, au cours de laquelle les fournisseurs présélectionnés sont invités à affiner leurs prix ou leurs conditions avant l’attribution du marché. TechTarget la mentionne parmi les étapes possibles après la remise des propositions. Si vous prévoyez d’en organiser une, indiquez-le dans l’appel d’offres afin que les fournisseurs établissent leurs prix en conséquence.

Puis-je envoyer un appel d’offres pour un travail que je n’ai pas entièrement défini ?

Oui, mais formulez-le autour du problème et demandez une approche par phases, idéalement avec une étape de découverte rémunérée. Exiger un prix fixe pour un périmètre non défini conduit à des offres gonflées ou à l’absence d’offres de la part des entreprises prudentes.

Sources

• Qu’est-ce qu’une demande de proposition (RFP) ? | TechTarget
• Gestion de projet du processus d’appel d’offres pour l’acquisition de logiciels | PMI
• Rédaction d’un appel d’offres, code de processus pour l’acquisition de logiciels | PublicCode.net
• Cour supérieure de Californie, comté de San Francisco — appel d’offres informatique
• Appel d’offres pour le développement, l’exploitation et la maintenance du système SECOORA

Recommandé

• Appel d’offres pour le développement logiciel : modèle, grille d’évaluation et guide de sécurité
• Développer ou acheter un logiciel : une liste de contrôle pour les dirigeants
• Comment choisir une entreprise de développement logiciel sur mesure : un cadre en 12 points
• Estimation d’un projet logiciel : guide pratique pour les chefs de projet