Comparer deux devis de développement à périmètre égal

Deux devis de développement ne sont presque jamais comparables tels quels. Prenons un responsable d’exploitation qui consulte trois prestataires pour un outil de suivi des chantiers. Les montants vont du simple au triple. Le moins cher tient sur deux pages, le plus cher en fait vingt. Entre les deux, un prestataire a chiffré « une première version » sans préciser ce qu’il met dedans. Prendre le moins cher serait une erreur. Prendre le plus cher, peut-être aussi. Le vrai problème n’est pas le prix : aucun des trois ne décrit le même objet.

Avant de regarder le total, regardez ce qu’il contient

Un devis de développement, c’est une liste de choses que le prestataire s’engage à livrer, et surtout une liste de choses dont il ne parle pas. La première est écrite. La seconde se devine. Pour comparer, il faut d’abord forcer les devis à tenir dans la même grille. Nous en utilisons une, toujours la même, en huit lignes :

• les fonctionnalités couvertes, écran par écran, avec ce que chacun permet de faire ;
• la reprise des données existantes : quels fichiers, combien de lignes, qui les nettoie ;
• les interfaces avec vos autres logiciels : devis, comptabilité, paie, planning ;
• la formation des utilisateurs, et pas seulement du responsable du projet ;
• la maintenance la première année : corrections comprises ou facturées ;
• la propriété du code et des données ;
• la réversibilité : comment vous repartez avec vos données si vous changez de prestataire ;
• le coût complet sur trois ans, abonnement, hébergement et évolutions compris.

Chaque devis passe dans cette grille. Quand une ligne reste vide, on pose la question au prestataire, par écrit. Sa réponse fait partie du devis. C’est en général à ce moment que les montants se rapprochent : le devis de deux pages grossit, et celui de vingt pages se révèle parfois raisonnable.

Les lignes absentes coûtent plus cher que les lignes écrites

Prenez la reprise des données. Imaginons un bureau d’études qui travaille depuis dix ans avec un fichier de prix unitaires copié, modifié, complété par cinq personnes différentes. Il y a des doublons, des lignes sans unité, des articles qui n’existent plus. Le devis qui dit « import des données existantes » sans en dire plus ne chiffre pas ce nettoyage. Celui qui le chiffre paraît plus cher, mais il est le seul honnête. Nous avons détaillé comment structurer la migration de vos données. Même chose pour les interfaces. « Compatible avec votre logiciel de comptabilité » ne veut rien dire tant qu’on ne sait pas quelle donnée passe, dans quel sens, à quelle fréquence, et qui s’en occupe quand ça casse.

La formation est le poste le plus souvent réduit à une ligne : « une demi-journée de formation ». Pour qui ? Si vos vingt chefs de chantier doivent saisir dans l’outil, une demi-journée pour le seul conducteur de travaux ne suffira pas. La maintenance de la première année est rarement explicite non plus. Un défaut découvert trois semaines après la mise en route, est-ce une correction gratuite ou une évolution payante ? La frontière entre les deux doit être écrite dans le devis. Sinon elle sera tranchée après, et rarement en votre faveur.

À qui appartient l’outil une fois le projet terminé

C’est la question que les dirigeants posent le moins et qui compte le plus. Trois cas existent. Le prestataire développe un outil et vous en cède le code : vous pouvez le confier à quelqu’un d’autre demain. Le prestataire développe sur sa propre plateforme et vous louez l’usage : vous ne possédez rien, vous payez tant que vous utilisez. Le prestataire assemble des briques d’un éditeur tiers : vous dépendez de deux acteurs au lieu d’un. Aucun de ces trois modèles n’est mauvais en soi. Ce qui est mauvais, c’est de ne pas savoir dans lequel on signe.

Les données suivent la même logique. Demandez, par écrit, sous quel format et dans quel délai vous pouvez récupérer l’intégralité de vos données si vous arrêtez. Un export dans un format lisible par un tableur, livré sous un mois, c’est une réponse. « On verra le moment venu », c’est aussi une réponse, et elle doit peser dans la comparaison. Il arrive qu’une entreprise reste des années de plus sur un outil qu’elle n’aime plus, simplement parce que personne n’a posé cette question au départ.

Comparez un coût sur trois ans, pas un prix de départ

Le total en bas du devis est un prix d’entrée. Ajoutez-y l’hébergement mensuel, l’abonnement s’il y en a un, la maintenance à partir de la deuxième année, les deux ou trois évolutions que vous demanderez forcément, et le temps de vos propres équipes pendant le projet. Faites ce calcul pour chaque devis, sur trois ans. Il arrive que le devis le plus bas devienne le plus cher, parce que son abonnement mensuel ou son taux horaire d’évolution rattrape l’écart en dix-huit mois.

Ce travail de mise à plat prend une journée, parfois deux, et il oblige à poser des questions gênantes aux prestataires. C’est là qu’un tiers indépendant est utile : quelqu’un qui ne vend pas le développement, qui n’a pas d’éditeur à placer et qui ne touchera rien sur le choix final. Son rôle n’est pas de désigner un gagnant. Il est de s’assurer que les devis décrivent enfin le même objet, et que vous signez en sachant ce que vous achetez. Dans l’exemple du début, le bon choix est souvent celui qui paraissait intermédiaire : ni le moins cher, ni le plus cher, mais le seul dont toutes les lignes sont remplies une fois réécrit.

Si vous n’en êtes pas encore aux devis, commencez plus tôt. Un cahier des charges que les prestataires comprennent évite la moitié de ces écarts. Et une demi-journée avec les personnes qui font le travail, sur un seul processus, suffit souvent à écrire un périmètre que les prestataires ne pourront plus interpréter chacun à leur façon. C’est le principe de notre workshop d’automatisation.