Achat de logiciel sur mesure : le guide 2026 de l'acheteur en 7 étapes
L'achat de logiciel sur mesure est le processus qui consiste à commander un logiciel développé spécifiquement pour vous par un prestataire externe : le business case, le cahier des charges, l'appel d'offres, l'évaluation des prestataires, le contrat, et le test de recette qui clôture le projet. Ce n'est pas un produit. C'est un processus d'achat que vous menez.
Cherchez sur Google, et vous obtiendrez neuf catalogues d'outils et une page de politique interne de l'UCLA de 900 mots. Le processus lui-même n'est traité nulle part, car les éditeurs d'outils écrivent ce qui se classe. Ce guide répond à la seconde question : comment acheter un logiciel qui n'existe pas encore ?
À retenir :
- L'achat de logiciel sur mesure est le processus qui consiste à commander un logiciel spécifique à un prestataire, pas à acheter un outil d'achat.
- Un cycle d'achat complet compte 7 étapes, du business case à la livraison acceptée, et prend généralement 10 à 16 semaines avant le développement.
- Neuf clauses contractuelles protègent votre budget ; la propriété de la PI, les critères de recette et les paiements par jalons sont celles qui mordent le plus.
L'achat de logiciel sur mesure n'est pas un logiciel de gestion des achats
Un logiciel de gestion des achats est un outil qui automatise les achats : bons de commande, validations, facturation, catalogues fournisseurs. L'achat de logiciel sur mesure est le processus qui consiste à commander un logiciel spécifique auprès d'un prestataire de développement. L'un est un produit que vous prenez sous licence. L'autre est un projet que vous menez, avec un contrat et un test de recette. Ce guide traite du second.
La confusion est compréhensible : le marché des outils est énorme et bien couvert. L'annuaire de fournisseurs d'Art of Procurement recense plus de 200 plateformes dans 19 catégories, et le guide d'achat 2026 de Brex aligne près de 4 000 mots pour en comparer cinq. Personne dans cet écosystème n'explique comment commander un logiciel en partant de zéro. C'est le vide que cet article comble.
Avant de commencer : le sur-mesure est-il vraiment le bon choix ?
Le sur-mesure est le bon choix quand le logiciel est au cœur de votre façon de travailler et qu'aucun produit existant ne couvre le processus sans bricolage. C'est le mauvais choix quand un produit sous licence couvre déjà 80 % du besoin. Décidez honnêtement avant de dépenser un euro dans un appel d'offres de logiciel sur mesure.
| Option | Gagne quand | Attention à |
|---|---|---|
| SaaS sur étagère | Le besoin est générique (paie, CRM, facturation) et une couverture à 80 % suffit | Les frais par siège s'accumulent ; vous louez, vous ne possédez jamais |
| Personnaliser une plateforme | Une plateforme convient presque, et votre cas limite relève de la configuration, pas d'une refonte | La dette de personnalisation ; les mises à jour cassent vos modifications |
| Développement sur mesure complet | Le logiciel est votre processus, vos concurrents ne peuvent pas l'acheter, et vous avez besoin de la PI | Vous portez le risque de développement, le contrat doit donc le répartir |
Vous hésitez encore sur la ligne qui vous concerne ? Notre grille de score développer ou acheter tranche la question du faire ou acheter ; ce guide répond à la question suivante : comment mener l'achat une fois la décision prise.
Ensuite, posez le business case par écrit. Un modèle de justification d'achat logiciel d'une page suffit :
Problem: What is broken, in one sentence
Current cost: What it costs today (hours per week x rate, or lost revenue)
Outcome: The measurable result the software must produce
Ceiling: The maximum budget, and the date the money runs outMême un achat mené à deux personnes profite d'une politique d'achat écrite : un paragraphe sur qui valide les dépenses et qui signe. Cela évite le flou du « le fondateur a dit oui en appel » qui fait couler la recette.
Le processus d'achat de logiciel sur mesure en 7 étapes
Le processus d'achat de logiciel sur mesure compte sept étapes, et six se déroulent avant que quiconque n'écrive une ligne de code. Le parcours complet, une ligne chacune :
- Besoin et business case : prouver que le problème vaut de l'argent
- Cahier des charges (SOW) : écrire noir sur blanc ce que « terminé » veut dire
- Veille marché : présélectionner les prestataires qui font ce type de travail
- RFP / RFQ : envoyer le même brief à tous
- Évaluation des prestataires : noter les réponses sur des preuves, pas au feeling
- Négociation et contrat : coucher les neuf clauses par écrit
- Livraison et recette : tester contre les critères de l'étape 2
Ces fourchettes sont notre interprétation des missions PME typiques, pas un benchmark mesuré : un renouvellement de gré à gré se boucle en trois semaines, un appel d'offres réglementé prend six mois.
| Étape | Semaines typiques | Livrable produit | Responsable |
|---|---|---|---|
| 1. Besoin et business case | 1 à 2 | Justification d'une page | Vous (acheteur) |
| 2. Cahier des charges | 2 à 4 | SOW et critères de recette | Vous, avec l'apport du prestataire |
| 3. Veille marché | 1 à 2 | Liste restreinte de 5 à 8 prestataires | Vous |
| 4. RFP / RFQ | 2 à 3 | Brief envoyé et réponses reçues | Vous, puis les prestataires |
| 5. Évaluation des prestataires | 1 à 2 | Grille d'évaluation notée | Vous |
| 6. Négociation et contrat | 2 à 3 | Accord signé | Les deux, plus le juridique |
| 7. Livraison et recette | court sur tout le développement | PV de recette signé | Les deux |
| Total avant développement | 10 à 16 | Contrat signé et SOW testable | Vous |
1. Besoin et business case
Commencez par la synthèse d'une page ci-dessus. Dans nos missions, les projets qui la sautent revoient leur périmètre en plein développement, au moment où les changements coûtent de l'argent réel au lieu d'un paragraphe. Elle fixe aussi le plafond budgétaire que vous annoncerez dans l'appel d'offres.
2. Cahier des charges (SOW)
Le cahier des charges transforme le business case en une spécification que les deux parties peuvent discuter : fonctionnalités incluses et exclues, intégrations, planning, et les critères de recette auxquels la livraison sera testée. Comment cadrer un projet d'application web se rembourse tout seul à cette étape, ou cadrez les exigences avec l'IA pour un premier jet plus rapide.
3. Veille marché
Constituez une liste restreinte de cinq à huit prestataires ayant des références récentes dans votre domaine. Demandez à vos pairs qui ont livré des travaux similaires ; examinez les études de cas de votre secteur, pas les pages d'accueil. Ignorez les annuaires classés par commission d'apport.
4. RFP / RFQ
Envoyez à chaque prestataire présélectionné le même brief et exigez le même format de réponse. Une RFP (request for proposal) demande comment ils construiraient la solution ; une RFQ (request for quotation) demande combien coûte un périmètre défini. Pour un achat de logiciel sur mesure, la RFP vient en premier.
5. Évaluation des prestataires
Notez chaque réponse avec la même grille d'évaluation, en pondérant les références et les droits d'audit de code plus que le prix. La proposition la moins chère est généralement celle qui a chiffré le moins de travail. Appelez vous-même les références.
6. Négociation et contrat
Prenez la proposition gagnante et greffez-y les neuf clauses ci-dessous. Négociez d'abord les critères de recette et les paiements par jalons, le prix en dernier : le prix est la condition la plus facile à bouger, la recette est celle qui mérite qu'on se batte.
7. Livraison et recette
La livraison, ce n'est pas « ils ont envoyé le code ». La recette signifie que le logiciel passe les critères du SOW dans votre environnement, avec la cession de PI signée et le code source remis. Retenez le dernier jalon de paiement jusqu'à ce que ce test passe.
L'appel d'offres qui vous obtient de vrais devis
Un appel d'offres sans critères de recette est un devis pour un travail que personne n'a défini. Le squelette ci-dessous est le modèle d'appel d'offres de logiciel sur mesure que nous aimerions que chaque acheteur nous envoie. Copiez-le, remplissez les blancs, et cinq prestataires chiffreront un même périmètre, pas cinq suppositions.
CUSTOM SOFTWARE RFP
1. Company context
Who you are, team size, the system this replaces or connects to
2. Problem statement
The broken process, what it costs you today, who feels it
3. Scope
In: the features and integrations the first release must ship
Out: anything you have decided to defer
4. Technical constraints
Stack preferences, hosting rules, compliance (GDPR, HIPAA), SSO
5. Timeline
Hard dates, and what happens if you miss them
6. Budget range
A ceiling, not a target. Vendors price to the number you give.
7. Acceptance criteria
The pass/fail tests the final delivery must clear before sign-off
8. Evaluation criteria
How you will score responses, and the weight of price vs. references
9. Response format
Page limits, the questions to answer, and the reply deadlineIncluez trois éléments par-dessus tout : plafond budgétaire, critères de recette, format de réponse. Ce sont eux qui transforment des pitchs vagues en devis comparables.
Retirez trois éléments : les prescriptions d'implémentation (« utilisez des microservices »), les NDA avant la présélection, les annexes d'exigences de 40 pages. Vous achetez un résultat, pas une architecture.
Deux remarques pratiques : envoyez exactement le même document à chaque prestataire, car des réponses uniformes sont la seule façon de donner un sens à une grille d'évaluation ; et indiquez vos pondérations d'évaluation dans l'appel d'offres lui-même. Les prestataires écrivent des propositions plus affûtées quand ils savent que les références pèsent plus que le prix.
Comment évaluer un prestataire de logiciel sur mesure ?
Évaluer un prestataire, c'est noter chaque proposition avec la même grille pondérée par des preuves, pour que la décision survive à un second examen. Le prix mérite moins de poids que la plupart des acheteurs ne lui en donnent : les propositions qui sous-enchérissent ont généralement chiffré le moins de travail. La grille que nous recommandons pour les budgets PME :
| Critère | Poids | Guide de notation |
|---|---|---|
| Références dans votre domaine | 25 % | 5 : deux références que vous avez réellement appelées, dans votre secteur. 1 : un mur de logos |
| Droits d'audit de code | 15 % | 5 : accepte par écrit une revue de code par un tiers avant le paiement final |
| Santé financière | 10 % | 5 : rentable, historique sur plusieurs années. 1 : ne peut pas le démontrer |
| Posture sécurité | 15 % | 5 : SDLC documenté, analyse des dépendances, accès au moindre privilège |
| Continuité et ancienneté de l'équipe | 15 % | 5 : équipe nommée, faible turnover. 1 : « nous affecterons l'équipe après signature » |
| Rythme de communication | 10 % | 5 : démo hebdomadaire actée par écrit. 1 : « on utilise Slack » |
| Discipline PI | 10 % | 5 : cession claire en œuvre pour le compte, pas de noyau propriétaire réutilisé |
Les pondérations sont un point de départ. Ajustez-les, mais faites-les sommer à 100 et notez-les avant de lire la première proposition. Notre classement des sociétés de développement applique la même discipline ; ce que les services de développement incluent réellement vous aide à comparer les lignes de devis à périmètre égal.
Checklist de due diligence pour l'acquisition de logiciel
Faites-la sur les deux meilleurs prestataires avant de signer, pas sur les cinq :
- Références vérifiées avec de vraies questions (ce qui a cassé, comment ils ont géré, les réengageriez-vous)
- Droits d'audit de code acceptés par écrit, avant le paiement du dernier jalon
- Santé financière confirmée (années d'activité, rentabilité, concentration client)
- Posture sécurité passée en revue (SDLC, contrôle d'accès, historique d'incidents)
- Continuité des profils clés confirmée (l'équipe du pitch est l'équipe du projet)
- Cession de PI revue par votre avocat, pas le leur
9 clauses contractuelles qui protègent votre budget
La clause qui protège votre budget n'est pas le prix. C'est le test de recette. Les recommandations d'achat de l'UCLA, la seule page institutionnelle dans le top dix de Google sur ce sujet, construisent leur conseil logiciel autour de cette idée : cahier des charges, propriété de la PI, test de recette et garantie, avant que le prix n'entre dans la pièce. Nous avons étendu cette taxonomie en neuf clauses pour les acheteurs privés.
Si vous assemblez un modèle de contrat d'achat de logiciel, ces neuf lignes en sont la colonne vertébrale :
| # | Clause | Pourquoi elle mord | Exemple de formulation en une ligne |
|---|---|---|---|
| 1 | Propriété de la PI / œuvre pour le compte | Sans elle, le prestataire garde les droits d'auteur et vous concède le logiciel en licence | « Tous les livrables sont des œuvres réalisées pour le compte ; au paiement, l'acheteur possède toute la PI sans réserve » |
| 2 | Critères et procédure de recette | La seule définition objective de « terminé » ; sans elle, les litiges deviennent des opinions | « La livraison n'est acceptée que lorsque tous les tests de l'annexe B passent dans l'environnement de l'acheteur » |
| 3 | Paiements liés aux jalons | Garde la trésorerie derrière l'avancement ; supprime le risque du 100 % à l'avance | « 20 % au lancement, puis 20 % par jalon, 20 % à la recette finale » |
| 4 | Gestion des changements | Empêche les disputes de périmètre de devenir des disputes de factures | « Toute modification du périmètre exige un avenant écrit chiffré (prix et délai) signé des deux parties » |
| 5 | Période de garantie | Oblige le prestataire à répondre du code après la remise | « Le prestataire corrige gratuitement les défauts constatés dans les 90 jours suivant la recette » |
| 6 | Protection de prix | Plafonne le rayon de dégâts des estimations optimistes | « Taux en régie figés 12 mois ; plafond à ne pas dépasser sans réapprobation écrite » |
| 7 | Spécifications de performance | Fait de « c'est lent » un manquement, pas une plainte | « Temps de chargement p95 sous 2 s ; p99 API sous 300 ms à 500 utilisateurs simultanés » |
| 8 | Personnel clé | Empêche le coup du pitch senior, du développement junior | « Les responsables nommés ne peuvent être réaffectés sans accord écrit de l'acheteur » |
| 9 | Résiliation et séquestre du code source | Votre sortie si le prestataire cale, coule ou part | « L'acheteur peut résilier pour motif légitime avec un préavis de 14 jours ; le code sous séquestre est libéré en cas d'insolvabilité » |
Oubliez-en une seule et vous financez un espoir. Si votre avocat a le temps pour trois clauses, donnez-lui les 1, 2 et 3.
Combien coûte un logiciel sur mesure, et comment structurer le paiement ?
Le périmètre fixe le prix, voilà pourquoi le SOW existe avant que le moindre devis n'ait un sens. L'ancre publiée est l'estimation de ScienceSoft : 200 000 à 400 000 $ et environ 10 mois pour un logiciel d'approvisionnement sur mesure de grade entreprise ; ScienceSoft y attribue le chiffre de 315 % de ROI à une étude Forrester Total Economic Impact.
Ce sont leurs chiffres pour les grands projets d'entreprise, pas les nôtres. Les développements PME plus petits, un outil interne, un portail client, une application mobile, atterrissent bien en dessous de cette fourchette ; traitez notre lecture PME comme une interprétation, et demandez trois devis avant d'en croire quoi que ce soit. Pour une ancre par type d'application, notre détail des coûts d'application mobile chiffre les développements par type d'app.
La structure du paiement compte autant que le total :
| Modèle | Gagne quand | Le risque pèse sur | Usage typique |
|---|---|---|---|
| Forfait | Le périmètre est figé et le SOW est blindé | Le prestataire (il absorbe les dépassements) | Premières versions bien définies |
| Régie | Le périmètre évoluera et vous faites confiance à l'équipe | Vous (chaque heure supplémentaire est facturée) | Projets à forte découverte ou de longue durée |
| Paiement par jalons | L'un ou l'autre modèle, avec des paiements liés aux livrables acceptés | Partagé (la trésorerie suit la preuve) | La plupart des développements sur mesure PME |
| Acheter, prendre sous licence ou s'abonner à la PI | Vous ne possédez le code que si le contrat cède la PI ; licence et abonnement SaaS le louent | Verrouillage prestataire avec licence et abonnement | Achetez quand le logiciel est stratégique ; abonnez-vous quand il est banalisé |
Notre recommandation : par défaut, des paiements par jalons sur un périmètre figé, 20 % ou moins au lancement, la dernière tranche conditionnée au test de recette. Le forfait uniquement si votre SOW survit à une lecture hostile ; la régie uniquement avec un prestataire avec qui vous avez déjà livré. Jamais 100 % à l'avance ; cette structure réapparaît plus bas.
Signaux d'alerte : comment les achats de logiciel sur mesure échouent vraiment
Payer 100 % à l'avance ne vous achète pas la priorité. Cela transfère tout le risque de livraison sur vous. Chaque signal d'alerte ci-dessous donne au prestataire un pouvoir de négociation que vous ne récupérerez pas :
- SOW flou. « Construisez-nous un CRM », pas de liste de fonctionnalités. Chaque terme non défini devient un avenant, chiffré sans concurrence.
- Pas de test de recette. « On le saura quand on le verra. » Alors vous ne le verrez jamais, car « terminé » n'a jamais été défini.
- Paiement à 100 % à l'avance. La trésorerie est votre seul levier après signature ; dépensez-la toute au premier jour et il ne vous reste rien.
- Pas de gestion des changements. Le périmètre gonfle, les factures gonflent, personne n'a signé la croissance.
- Cession de PI absente. Vous avez payé le logiciel et pris une licence en retour sans le remarquer.
- Pas de clause de personnel clé. L'équipe senior qui a gagné le pitch disparaît la semaine suivant la signature.
Nous répondons à des appels d'offres de logiciel sur mesure chaque trimestre côté prestataire, et deux schémas reviennent si régulièrement que nous les traitons comme le taux de base de l'échec d'achat : des appels d'offres sans aucun critère de recette, et des échéanciers de paiement qui placent la majorité à l'avance, donnant au prestataire toutes les raisons de déprioriser le projet une fois la trésorerie encaissée. Notre lecture, et c'est une interprétation, pas une mesure : les acheteurs qui négocient le prix le plus durement sont ceux qui ont sauté les deux clauses, recette et jalons, qui l'auraient protégé.
Les données de l'industrie pointent dans le même sens. Le Standish Group suit les résultats de projets depuis trois décennies via sa recherche CHAOS ; son constat récurrent est que les projets en difficulté, hors budget, en retard ou pauvres en fonctionnalités, surpassent en nombre les réussites propres, avec des exigences floues et un parrainage faible en tête des listes de causes.
Si vous ne corrigez qu'une chose, corrigez les critères de recette. C'est la clause qui rend toutes les autres applicables.
Comment Techsy aborde l'achat de logiciel sur mesure
Notre intake suit les mêmes sept étapes, de l'autre côté de la table. Nous produisons le SOW et les critères de recette avant de chiffrer, car chiffrer sur un brief vague est la façon dont les prestataires sous-estiment et les acheteurs surpaient. Les développements tournent en paiements par jalons, démos hebdomadaires, droits d'audit de code dans chaque contrat. Quand la recette passe, vous possédez la PI et le dépôt, pas une licence.
Limites honnêtes : si vous avez besoin d'un outil SaaS sous licence qui automatise les achats, nous sommes le mauvais choix. C'est un achat de produit, pas un développement ; un éditeur d'outils vous servira plus vite et moins cher. Nous prenons le travail sur mesure quand le logiciel est le processus et que la PI compte.
Si votre projet entre dans ce second panier, obtenez une consultation gratuite.
Questions fréquemment posées
Qu'est-ce que l'achat de logiciel ?
L'achat de logiciel est le processus d'acquisition d'un logiciel : définir le besoin, évaluer les options, négocier les conditions, accepter la livraison. Il couvre aussi bien les produits sous licence que les développements sur mesure. Ce guide se concentre sur le second : le processus qui va du business case à l'appel d'offres, au contrat et au test de recette.
Quels sont les 4 types d'achat ?
Les quatre types couramment cités sont l'achat direct (intrants de production), indirect (biens et services de fonctionnement), de biens et de services. Le logiciel chevauche l'indirect et les services : un outil sous licence est un achat indirect ; un développement sur mesure est une mission de services qui aboutit à un bien livré.
Quelle différence entre logiciel de gestion des achats et achat de logiciel sur mesure ?
Un logiciel de gestion des achats est un outil qui automatise les workflows d'achat, comme Tradogram ou Tipalti. L'achat de logiciel sur mesure est le processus qui consiste à commander un logiciel spécifique auprès d'un prestataire de développement. Vous cherchez la meilleure plateforme d'achat ? Vous voulez le premier ; ce guide est le second.
Combien de temps prend un achat de logiciel sur mesure ?
Comptez 10 à 16 semaines du business case au contrat signé sur une mission PME typique, avant que le développement ne commence ; traitez cela comme une interprétation, pas un benchmark. Un renouvellement de gré à gré se comprime en semaines ; un appel d'offres réglementé peut dépasser six mois.
Combien coûte un logiciel sur mesure ?
ScienceSoft estime 200 000 à 400 000 $ et environ 10 mois pour un logiciel d'approvisionnement sur mesure de grade entreprise, en attribuant un ROI de 315 % à une étude Forrester. Les développements PME plus petits atterrissent bien en dessous de cette fourchette. Pour un achat de logiciel sur mesure, le périmètre fixe le prix : l'appel d'offres et le SOW existent avant que le moindre devis n'ait un sens.
À qui appartient la PI d'un logiciel sur mesure ?
À celui que le contrat désigne. Sans clause explicite d'œuvre pour le compte ou de cession de PI, le prestataire garde les droits d'auteur et vous concède le logiciel en licence. Mettez la propriété par écrit, liée au paiement : au paiement final, l'acheteur possède tout. Attachez ce transfert à la dernière tranche conditionnée à la recette, pas au paiement de lancement, pour que la propriété ne bouge que lorsque le logiciel bouge.
RFP ou RFQ, de laquelle ai-je besoin ?
Une RFP (request for proposal) demande comment les prestataires résoudraient votre problème ; une RFQ (request for quotation) demande combien coûte un périmètre défini. Pour du logiciel sur mesure, envoyez d'abord la RFP : les prestataires doivent proposer une approche avant que le prix n'ait un sens. La RFQ vient une fois le SOW figé.
Forfait ou régie ?
Le forfait vous protège quand le SOW est blindé : le prestataire absorbe les dépassements. La régie convient aux travaux à forte découverte où le périmètre évoluera, mais vous portez le risque de dépassement. La plupart des acheteurs PME s'en sortent le mieux avec des paiements par jalons sur un périmètre figé, la dernière tranche conditionnée au test de recette.
Que doit contenir un cahier des charges ?
Un cahier des charges doit nommer les fonctionnalités incluses et exclues du périmètre, les intégrations, le planning, les critères de recette auxquels la livraison sera testée, et les jalons de paiement liés à chaque livrable. Si une condition n'est pas dans le SOW, elle n'est pas dans le projet.
À propos de l'auteur
Mert Batur est cofondateur de Techsy.io, où l'équipe livre des agents IA, des systèmes d'automatisation et des pipelines voix/SDR pour des clients B2B. Il écrit sur la stack d'outillage LLM que l'équipe Techsy utilise réellement en production. Il mène aussi les missions de livraison de logiciel sur mesure dont ce guide s'inspire, de la réponse à l'appel d'offres à la remise acceptée. Rejoindre sur LinkedIn.
Conclusion
L'achat de logiciel sur mesure se résume à des livrables, pas à des négociations : le business case d'une page, le SOW avec critères de recette, le squelette d'appel d'offres, la grille d'évaluation, le contrat à neuf clauses. Soignez ces cinq documents et la conversation avec le prestataire se mène toute seule. Suivez les sept étapes dans l'ordre, retenez le paiement final derrière le test de recette, et si vous voulez un second avis sur votre appel d'offres, obtenez une consultation gratuite.