Un appel d’offres logiciel est censé rendre les prestataires comparables. La plupart obtiennent l’inverse, parce qu’ils décrivent une solution avec assez de détail pour contraindre la réponse tout en omettant les informations dont n’importe qui aurait besoin pour la chiffrer. Le résultat, ce sont cinq devis séparés par un ordre de grandeur, tous formellement conformes, dont aucun ne mesure la même chose.

Le diagnostic habituel consiste à dire que les prestataires restent évasifs. C’est parfois vrai. Bien plus souvent, le document a demandé un chiffre que son propre contenu ne permettait pas de produire, et chaque prestataire a comblé les trous avec des hypothèses différentes.

Le test qui dit si votre appel d’offres fonctionnera : deux prestataires différents pourraient-ils le lire et aboutir en substance au même périmètre ? Si un document dit « gestion des utilisateurs » sans indiquer le nombre de rôles, si les permissions varient selon l’enregistrement, ou s’il faut se brancher sur un annuaire existant, l’un chiffre une semaine et l’autre deux mois. Les deux répondent honnêtement. Vous ne pouvez pas les comparer.

Pourquoi une liste de fonctions est le mauvais point de départ

Une liste de fonctions dit au prestataire ce que vous avez décidé, pas ce dont vous avez besoin. Cela compte, parce que la décision peut être mauvaise, et que celui qui le repère n’a aucun moyen de le dire dans la structure que vous avez imposée.

Elle masque aussi les informations qui pilotent le coût. En logiciel, la charge se loge dans les parties ingrates : combien de systèmes externes il faut relier, quel volume de données existantes doit être migré et dans quel état elles sont, combien de types d’utilisateurs distincts avec des droits différents, et quelles sont les obligations de conformité. Une liste de fonctions peut être longue et ne rien contenir de tout cela.

L’alternative n’est pas le flou. Décrivez le problème avec précision, énoncez les contraintes qui sont réellement figées, et laissez la proposition expliquer l’approche. Vous obtiendrez des réponses différentes, et les écarts seront informatifs au lieu d’être du bruit.

Ce que doit vraiment contenir un appel d’offres logiciel

Le problème métier et la définition du succès. Ce qui se passe aujourd’hui, ce qui devrait se passer à la place, et comment vous saurez que cela a marché. Les prestataires s’en servent pour contester le périmètre, ce qui est la chose la plus utile qu’ils puissent faire à ce stade.

Les volumes et l’échelle, avec des chiffres. Utilisateurs, transactions, enregistrements, croissance attendue. Cela seul élimine une grande part de l’écart entre les devis.

Les systèmes à connecter, nommés, avec une note indiquant si chacun dispose d’une interface documentée. Une seule intégration à un système ancien et non documenté peut coûter plus cher que tout le reste réuni.

Les données que vous possédez déjà. Quel volume, où elles résident et dans quel état elles sont. La migration est régulièrement la ligne la plus sous-estimée d’un projet.

Les contraintes réellement figées. Obligations réglementaires, lieu d’hébergement imposé, fournisseur d’identité existant, date immuable. Précisez lesquelles sont fermes et lesquelles sont des préférences, car les prestataires chiffrent les contraintes fermes de manière défensive.

Ce que vous ne demandez pas. Exclure explicitement certaines choses est l’un des moyens les moins coûteux de réduire l’écart entre les devis.

Votre fourchette de budget. La cacher ne fait pas baisser le prix. Elle produit des propositions dimensionnées pour un budget que personne ne connaît, et qu’il faudra refaire ensuite. Une fourchette permet aux prestataires de vous dire ce qui est faisable dedans. Notre guide des coûts du développement logiciel sur mesure détaille ce que chaque palier achète.

Les questions qui séparent les prestataires

Posez moins de questions, mais de meilleures. Celles-ci révèlent plus qu’une matrice de conformité de cent lignes.

Que construiriez-vous en premier, et pourquoi ? Le séquencement montre s’ils ont compris le problème ou seulement le document.

Quelle est la partie la plus risquée et comment la réduiriez-vous ? Un prestataire qui nomme un vrai risque est plus fiable que celui qui n’en signale aucun.

Qui exactement fera le travail ? Des noms, un niveau d’expérience et la part de leur temps. Une proposition rédigée par des gens qui ne la réaliseront pas est une déception classique.

Que se passe-t-il quand le périmètre change ? Il changera. La réponse vous dit comment la relation fonctionne sous pression, ce qui compte plus que le tarif journalier.

De quoi avez-vous besoin de notre part ? Les projets échouent sur la disponibilité côté client au moins aussi souvent que sur la capacité du prestataire, et celui qui le dit décrit la réalité au lieu de vendre.

Que possédons-nous à la fin ? Le code, l’infrastructure, les comptes, les données. Obtenez-le par écrit avant la sélection plutôt qu’après.

Lire les réponses

Le devis le moins cher reflète en général l’interprétation la plus étroite du périmètre, pas la plus grande efficacité, et l’écart ressort sous forme de demandes de modification une fois le travail lancé.

Regardez où chaque prestataire a mis son effort. Une proposition qui consacre sa longueur à l’intégration et à la migration des données a compris où se trouve la difficulté. Celle qui la consacre à la méthodologie et aux photos d’équipe ne s’est pas confrontée au problème.

Traitez les objections non sollicitées comme un bon signe. Un prestataire qui dit qu’une partie de votre périmètre est inutile, ou qu’une contrainte annoncée coûtera plus qu’elle ne rapporte, fait exactement le travail que vous voulez. Les prestataires qui approuvent tout sont plus faciles à lire et moins agréables à vivre.

Et vérifiez que chaque devis répond à la même question. Là où deux devis diffèrent d’un facteur trois, l’un a supposé quelque chose que le document ne disait pas, et découvrir lequel est plus utile que n’importe quelle grille de notation.

Quand ne pas en lancer un

Si le travail est petit, ou exploratoire, ou si vous ne savez pas encore ce dont vous avez besoin, l’appel d’offres est le mauvais instrument. Il coûte des semaines aux deux parties et crée une fausse impression de précision.

Dans ces cas, un cadrage payant vaut généralement mieux : une intervention courte qui produit une spécification que vous pourrez ensuite porter au marché, ou qui établit que la chose ne vaut pas la peine d’être construite. Les deux résultats valent mieux qu’une mise en concurrence sur un périmètre que personne ne savait définir. La discipline de cadrage de notre guide sur le développement de MVP s’applique directement.

Mecanik répond à des appels d’offres et aide aussi les organisations à les rédiger, dans le cadre de notre activité de développement logiciel. Les documents qui produisent de bons devis sont invariablement les plus courts, ceux qui contiennent de vrais chiffres.

Questions fréquentes

Que doit contenir un appel d’offres logiciel ? Le problème métier et la définition du succès, les volumes et l’échelle avec de vrais chiffres, les systèmes à intégrer nommés un par un avec la mention de leur interface documentée ou non, l’état des données à migrer, les contraintes réellement figées, ce qui est explicitement hors périmètre, et une fourchette de budget.

Dois-je indiquer mon budget dans l’appel d’offres ? Oui. Le cacher ne fait pas baisser le prix, cela produit des propositions dimensionnées pour un budget que personne ne connaît et qu’il faudra refaire ensuite. Une fourchette annoncée permet aux prestataires de vous dire ce qui est réellement faisable dedans et rend les réponses comparables.

Pourquoi les devis pour le même logiciel varient-ils autant ? En général parce que le document a laissé des trous et que chaque prestataire les a comblés avec des hypothèses différentes. Une ligne comme « gestion des utilisateurs », sans indication sur le nombre de rôles, les droits par enregistrement ou la connexion à un annuaire, peut honnêtement être chiffrée à une semaine ou à deux mois. L’écart est une propriété de l’appel d’offres, pas des prestataires.

Quelles questions révèlent un bon prestataire logiciel ? Ce qu’il construirait en premier et pourquoi, ce qu’il considère comme le plus risqué et comment il le réduirait, qui exactement fera le travail et sur quelle part de son temps, comment les changements de périmètre sont traités, ce dont il a besoin de votre part, et ce que vous possédez à la fin.

Quand vaut-il mieux ne pas faire d’appel d’offres ? Quand le travail est petit, exploratoire, ou que vous ne savez pas encore définir votre besoin. Une mise en concurrence sur un périmètre indéfini coûte des semaines aux deux parties et crée une fausse précision. Un cadrage payant qui produit une spécification, ou qui établit que le projet ne vaut pas la peine, est le meilleur instrument.