Cahier des chargesChoisir un prestataireMéthodePrototype
Appel d'offres pour un développement logiciel : le rédiger et le dépouiller
10 min de lecture
Un appel d'offres pour un développement logiciel est un dossier envoyé à plusieurs prestataires pour obtenir des réponses comparables à un même besoin : contexte, objectifs, périmètre, contraintes, format de réponse et critères de choix. Bien rédigé, il fait gagner des semaines et évite le piège classique du devis le moins cher qui ne couvre pas le même projet. Mal rédigé, il produit des réponses impossibles à comparer.
Cet article donne le plan du dossier, les pièces qui révèlent vraiment la qualité d'un prestataire, et une grille pour dépouiller les réponses. Il se place entre deux sujets traités ailleurs : le contenu fonctionnel du besoin, décrit dans notre article sur le cahier des charges, et la lecture des devis une fois reçus, détaillée dans notre comparatif de devis.
Appel d'offres privé ou marché public
Une entreprise privée organise sa consultation comme elle l'entend : nombre de candidats, calendrier, critères, négociation. Les conseils qui suivent s'adressent à elle.
Un acheteur public, en revanche, relève du Code de la commande publique, avec ses propres règles de publicité, de mise en concurrence et de choix de l'offre. Ce cadre n'est pas traité ici : la Direction des affaires juridiques de Bercy publie ses conseils aux acheteurs, qui font référence.
Si vous ne savez pas encore quels prestataires pourraient réaliser le projet, commencez par une étape plus légère : une demande d'information, envoyée plus largement, qui interroge chaque prestataire sur son expérience, ses projets types, son mode d'engagement et sa première approche. Les réponses constituent votre liste courte. Le dossier complet ne part ensuite qu'aux prestataires que vous envisagez vraiment de retenir, ce qui garde l'effort raisonnable des deux côtés.
Avant de rédiger : trois décisions
Décidez ce que vous achetez. Un résultat livré à prix fixe, ou du temps de développeurs facturé à l'heure ? Le format de réponse n'est pas le même, et les deux offres ne se comparent pas entre elles. Les différences sont détaillées dans notre article forfait ou régie.
Décidez d'une fourchette de budget. La donner aux candidats n'est pas un aveu de faiblesse : c'est le seul moyen d'obtenir des propositions de périmètre comparable. Sans elle, l'un chiffre l'essentiel et l'autre une solution complète, et vous comparez deux projets différents.
Décidez qui choisira. Le dirigeant, un responsable métier, la DSI si elle existe, un futur utilisateur clé. Un comité constitué avant la consultation note les réponses selon la même grille ; un comité constitué après tranche souvent sur l'intuition.
Le plan du dossier, section par section
| Section | Ce qu'elle contient |
|---|---|
| 1. Présentation | L'entreprise, son activité, les interlocuteurs de la consultation |
| 2. Contexte | Les outils actuels, ce qui ne fonctionne plus, pourquoi maintenant |
| 3. Objectifs | Ce qui doit changer, mesuré si possible (ressaisies supprimées, délais de traitement) |
| 4. Périmètre | Les utilisateurs, les processus couverts, ce qui est exclu |
| 5. Exigences | Fonctions attendues, par ordre de priorité, avec le cahier des charges en annexe |
| 6. Contraintes | Outils à connecter, hébergement, données personnelles, accessibilité, appareils |
| 7. Après la livraison | Maintenance, hébergement, évolutions, support |
| 8. Contrat | Propriété du code, réversibilité, confidentialité, modalités de paiement attendues |
| 9. Consultation | Calendrier, questions, format et contenu de la réponse, critères d'évaluation |
Trois sections font la différence.
Le contexte. Un prestataire qui comprend pourquoi le projet existe propose mieux qu'un prestataire qui lit une liste de fonctions. Décrivez les irritants concrets : le tableur partagé qui se corrompt, la double saisie entre deux logiciels, le planning qui vit sur un tableau blanc.
Les priorités. Classez les fonctions entre indispensables, utiles et souhaitables. Sans ce classement, chaque candidat arbitre à votre place, et les réponses deviennent incomparables.
Le format de réponse. Imposez une structure commune : compréhension du besoin, solution proposée, méthode, équipe, planning, maintenance, prix détaillé par lot, hypothèses retenues. Vous lirez des réponses alignées au lieu de plaquettes commerciales.
Les pièces qui révèlent un prestataire
Un mémoire technique se rédige bien, quel que soit le niveau réel du prestataire. Certaines pièces sont plus difficiles à enjoliver.
- Un prototype ou une maquette des écrans principaux. C'est la preuve la plus directe que le besoin est compris. Un prestataire qui montre vos écrans, avec vos termes métier, a fait le travail de compréhension que les autres promettent. Précisez ce que vous attendez et sur quel périmètre.
- Les hypothèses du chiffrage. Tout prix repose sur des hypothèses : nombre d'écrans, volume de données, connexions, reprise de l'existant. Demandez-les par écrit ; ce sont elles qui expliquent les écarts de prix.
- Un exemple de livrable réel. Un logiciel en production, un extrait de documentation, un exemple de compte rendu de suivi.
- Le projet de contrat. Les conditions sur la propriété du code, la réversibilité et la maintenance sont aussi importantes que le prix. Les points à vérifier sont listés dans notre article sur les clauses du contrat de développement.
Un mot sur le prototype : le demander dans une consultation a un coût pour les candidats. Annoncez-le, limitez le périmètre aux écrans clés, et acceptez qu'un prestataire qui le propose déjà dans sa démarche commerciale le fournisse dans son format habituel. C'est ce que décrit notre article sur le fait de voir son logiciel avant de le payer.
Les erreurs de rédaction les plus courantes
- Décrire la solution au lieu du besoin. « Une application React avec tel module » ferme la porte aux propositions plus simples. Décrivez le problème, et laissez les candidats proposer.
- Copier le cahier des charges d'un autre projet. Les exigences génériques produisent des réponses génériques.
- Oublier les données. Si le prestataire héberge des données personnelles pour votre compte, il agira comme sous-traitant au sens du RGPD, et l'article 28 du règlement impose un contrat qui encadre ce traitement. Demandez son projet de contrat dès la réponse.
- Laisser trop peu de temps. Une réponse sérieuse demande de comprendre votre métier, poser des questions et chiffrer. Un délai trop court favorise les réponses toutes faites.
Le calendrier de la consultation
Une consultation se déroule en étapes datées, communiquées dès l'envoi :
- Envoi du dossier à la liste courte de prestataires présélectionnés.
- Période de questions, avec des réponses partagées à tous les candidats, pour que chacun travaille sur la même information.
- Remise des réponses à une date fixe, dans le format demandé.
- Analyse selon la grille, par le comité, chacun notant de son côté avant la mise en commun.
- Soutenance des finalistes : présentation, démonstration, questions.
- Décision et retour à tous les candidats, y compris ceux qui ne sont pas retenus.
La soutenance est souvent l'étape décisive. Vous y rencontrez l'équipe qui travaillera réellement sur le projet, pas seulement le commercial, et vous voyez comment elle répond à une question imprévue.
La grille de dépouillement
Fixez la grille avant d'ouvrir les réponses, et partagez-la avec les candidats dans le dossier. Voici une base à adapter à votre projet.
| Critère | Ce que l'on regarde | Poids indicatif |
|---|---|---|
| Compréhension du besoin | Reformulation juste, questions pertinentes, prototype | Fort |
| Solution proposée | Adéquation aux priorités, simplicité, choix techniques expliqués | Fort |
| Méthode et engagements | Étapes, points de validation, engagement sur le résultat ou sur le temps | Moyen |
| Équipe | Personnes réellement affectées, interlocuteur unique, continuité | Moyen |
| Après la livraison | Maintenance, hébergement, délais de correction | Moyen |
| Contrat | Propriété du code, réversibilité, garanties | Moyen |
| Prix | Total, détail par lot, coûts récurrents, hypothèses | Fort |
Pour chaque critère, notez sur une échelle courte et écrivez une phrase de justification. La phrase compte plus que la note : c'est elle qui permet de défendre la décision, et de comprendre six mois plus tard pourquoi un candidat a été écarté.
Les signaux d'alerte dans une réponse
- Une réponse générique, qui pourrait s'appliquer à n'importe quel projet et ne reprend aucun de vos termes métier.
- Un prix sans hypothèses, ou un prix très inférieur aux autres sans explication du périmètre.
- Une équipe floue : « nos experts », sans noms ni rôles.
- Rien sur l'après-livraison, comme si le logiciel n'avait pas besoin d'être hébergé, corrigé et mis à jour.
- Un silence sur la propriété du code et sur la réversibilité.
D'autres critères pour juger un prestataire, au-delà de la consultation, sont listés dans notre article sur le choix d'une agence de développement.
Après le choix
Le prestataire retenu n'est pas encore sous contrat. La négociation finale porte rarement sur le prix seul : elle précise le périmètre du premier lot, les étapes de validation, les conditions de maintenance et les clauses de propriété. Les droits sur le code sont définis au cas par cas dans le contrat : faites relire ce document par votre conseil avant de signer.
Chez LPR Studio, nous répondons aux consultations avec un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés. Il vous permet de juger notre compréhension de votre besoin sur pièce, avant toute décision. Trois formules sont ensuite possibles : forfait à prix fixe, abonnement sans payer le développement, ou édition SaaS.