Comment choisir un partenaire de développement logiciel

Un cabinet d’ingénierie logicielle qui publie un guide pour en choisir un a un conflit d’intérêts évident ; commençons donc par la seule référence qui vaille ici : une part importante de notre activité consiste à reprendre des projets qui ont mal tourné ailleurs. Sauvetages, reconstructions, modernisations de systèmes de trois ans déjà vieillissants. Nous voyons le mauvais choix de l’intérieur, dix-huit mois après la signature, et le schéma se répète avec une régularité troublante. L’acheteur n’a presque jamais choisi par négligence. Il a mal choisi parce que le processus d’évaluation habituel mesure les mauvaises choses.

Vues de l’extérieur, les sociétés de développement se ressemblent toutes : mêmes études de cas, mêmes logos, mêmes promesses d’ingénieurs seniors et de livraison agile, notre site compris. Quant aux outils dont dispose l’acheteur pour départager (portfolios, références, grilles tarifaires), ce sont précisément ceux que chaque cabinet polit depuis des années. Cette liste de contrôle sert à regarder derrière.

Pourquoi les références et les portfolios induisent en erreur

Un portfolio est un florilège. Chaque cabinet y montre ses trois meilleurs projets, et cette sélection n’apprend rien sur la mission médiane : c’est un biais du survivant par construction. Les projets qui ont dérapé d’un an, ceux qui ont été livrés puis discrètement abandonnés, ceux qui se sont terminés en litige ne figurent nulle part, et la confidentialité fournit à chacun une raison respectable d’expliquer les trous. Un portfolio donne le plafond d’un cabinet. Vous, vous vivrez avec sa médiane.

Les références souffrent du même défaut, sous un visage plus aimable : c’est le cabinet qui les choisit. On vous donnera les trois clients les plus satisfaits des cinq dernières années, jamais le numéro de celui dont le projet a été abandonné. Même une référence sincèrement enthousiaste reste une preuve faible, car le résultat tenait à l’équipe précise mobilisée cette année-là, et les personnes qui ont construit l’étude de cas vitrine ont peut-être changé deux fois d’employeur depuis.

Les appeler vaut quand même la peine, à condition de changer de questions. Non pas « étiez-vous satisfait ? », qui appelle un oui récité, mais « racontez-moi le pire mois du projet, et ce qu’ils ont fait à ce moment-là ». Toute mission d’une certaine taille connaît un mauvais mois. Savoir si le cabinet a mis le problème sur la table tôt, rechiffré honnêtement et corrigé, ou s’il s’est tu en continuant à facturer : c’est l’information la plus instructive qu’une référence puisse vous livrer.

Ce qui fait un bon partenaire d’ingénierie logicielle : quatre signaux

Le premier tient à leur manière d’estimer. Un cabinet qui avance un chiffre avant d’avoir compris comment vous travaillez vous renseigne surtout sur lui-même. Une vraie estimation découle de vraies questions : les processus, les données, les systèmes déjà en exploitation, les exceptions qui font que ce métier est le vôtre. Si le prix arrive avant ces questions, il n’a pas été déduit du projet ; il a été fixé pour le remporter. L’écart entre ces deux chiffres refera surface plus tard, déguisé en demandes de changement. Pour disposer d’un point de repère avant le premier appel, voici ce qui détermine réellement le coût d’un logiciel sur mesure.

La manière d’estimer annonce la manière de construire. Un cabinet qui devine le prix devinera aussi le système.

Le deuxième, c’est ce à quoi ils disent non. Posez la question sans détour : quels projets avez-vous refusés, et pourquoi ? Un cabinet incapable d’en citer un seul accepte tout ce qui paie, et le projet ira alors à qui est libre plutôt qu’à qui convient ; ou bien il n’a jamais sérieusement réfléchi à ce dans quoi il est réellement bon. La forme de ses refus est la carte la plus honnête de sa compétence que vous obtiendrez dans un processus commercial.

Le troisième, c’est qui écrit le code. Les personnes présentes aux trois premières réunions ne sont généralement pas celles qui construiront le système. Demandez à rencontrer le responsable technique qui porterait le projet, l’ingénieur et non le directeur de la production, puis posez-lui des questions techniques sur votre problème. Un cabinet qui a confiance en ses ingénieurs vous les présente sans hésiter. Celui qui vous maintient au niveau commercial entretient une impression.

Le quatrième, c’est la forme du transfert. La fin d’une mission est le moment où les intérêts divergent le plus : jusque-là, le prestataire a intérêt à bien faire, alors que la documentation, la reprise et votre autonomie sont les seules parties qui ne lui coûtent que de l’argent. Demandez donc des preuves : un document d’architecture anonymisé, un runbook, un dossier de transfert issu d’un projet terminé. Un cabinet capable d’en produire un l’a déjà fait et s’attend à ce que vous puissiez fonctionner sans lui. Celui qui parle de partenariat au lieu de sortir un document décrit poliment une dépendance.

Ces quatre signaux font la différence entre un partenaire d’ingénierie logicielle et un prestataire qui vend des heures : l’un répond du résultat, l’autre de la feuille de temps.

Signaux d’alerte qui justifient de partir

Les seniors de l’avant-vente, les juniors à l’exécution. C’est le cas le plus fréquent. Des ingénieurs seniors mènent l’avant-vente et le cadrage ; dès le deuxième mois, l’historique des commits raconte autre chose. La parade est structurelle, elle ne relève pas de la confiance : des personnes nommées au contrat, le droit de rencontrer tout remplaçant avant son affectation, et un œil sur qui se présente réellement aux points quotidiens.

La facturation à l’heure sans discipline de périmètre. La régie n’est pas mauvaise en soi. Mais des heures sans jalons, sans périmètre écrit et sans définition du « terminé » signifient que le prestataire gagne d’autant plus que le projet dure, et rien dans la structure ne s’y oppose. La bonne question n’est pas « à l’heure ou au forfait », elle est « qui porte la responsabilité de l’estimation ». Si la réponse est vous, alors la discipline de périmètre, c’est vous. (Nous avons détaillé l’alternative dans pourquoi le forfait échoue, et ce que corrige la facturation au jalon.)

« On peut commencer lundi. » Un cabinet dont toute l’équipe est libre demain vous renseigne sur la demande pour son travail. Des creux, cela arrive : un projet s’achève, une date de démarrage glisse. Mais une équipe senior entière en intercontrat est rare dans n’importe quel cabinet qui vaille la peine d’être engagé. Traitez une disponibilité immédiate à grande échelle comme vous traiteriez un chirurgien sans liste d’attente.

Aucune opinion sur les parties ingrates de votre secteur. Chaque domaine a sa mécanique sans gloire : rapprochements, cas réglementaires limites, exceptions tarifaires, règles de planification. C’est là que les projets coulent vraiment. Un partenaire n’a pas besoin d’expérience préalable dans votre secteur, mais il doit s’animer sur ces sujets-là, parce que c’est ce qu’il passera l’essentiel du projet à construire. Si la conversation dérive sans cesse vers la surface excitante du produit, les neuf dixièmes ternes seront appris à vos frais.

Huit questions pour le premier appel

Les signaux se lisent plus facilement quand on les demande. Ces huit questions méritent d’être posées mot pour mot, à peu près dans cet ordre.

Écoutez la précision, et un léger inconfort. Les bonnes réponses citent de vrais projets, de vraies erreurs et de vraies contraintes ; les mauvaises sont lisses, génériques et immédiatement complaisantes. La question six teste le jugement sur le périmètre : le bon partenaire plaidera pour une première version resserrée en 2 à 3 mois plutôt que pour une plateforme en un an, et vous dira quelles parties du brief peuvent attendre. La question sept est le test de la dépendance. Un partenaire qui compte mériter la reconduction rend le départ bon marché : vos dépôts, votre infrastructure, la documentation comme livrable. Celui qui compte vous tenir restera vague.

Quand changer de partenaire de développement logiciel

Beaucoup de lecteurs de cette liste ne choisissent pas un premier partenaire : ils se demandent s’il faut remplacer l’actuel. Les signes avant-coureurs tiennent rarement à une catastrophe isolée. Ils tiennent à une dérive : des échéances manquées qui ne s’accompagnent plus d’explications, un système que seul le prestataire sait déployer, des demandes d’évolution plus chères à chaque trimestre et une équipe qui tourne plus vite qu’elle ne documente. Si deux de ces constats se vérifient, appliquez la liste ci-dessus à votre partenaire actuel, comme si vous le rencontriez pour la première fois.

Si vous décidez de changer, l’ordre des opérations compte plus que le nouveau prestataire. Sécurisez d’abord les dépôts, les comptes d’infrastructure et les identifiants ; récupérez la documentation existante, aussi maigre soit-elle ; et organisez une passation par étapes plutôt qu’une bascule unique. Reprendre des systèmes de cette manière représente une large part de notre activité : voir changer de partenaire de développement logiciel sans perdre le projet et moderniser l’existant sans tout réécrire.

Réduire le risque : commencer plus petit que le contrat

Le problème le plus profond du choix d’un partenaire ne tient à aucun signal en particulier : il tient à ce que le processus habituel demande de tout décider d’un coup, deux appels, une proposition, un engagement à six chiffres. Aucun entretien ne donne de certitude sur le comportement d’un cabinet en conditions réelles. On peut en revanche en acheter un petit échantillon. Plutôt que de signer le gros contrat, commencez par une courte mission de diagnostic : 1 à 2 semaines à l’intérieur d’un seul processus, débouchant sur une estimation, un schéma d’architecture et un calcul du délai d’amortissement qui vous appartiennent, quelle que soit la suite.

Un diagnostic transforme chaque signal de cet article en observation. Vous regardez comment ils estiment au lieu de le leur demander. Vous rencontrez les ingénieurs qui construiraient vraiment, parce qu’un diagnostic est un travail technique dont une équipe commerciale est incapable. Et vous repartez avec un livrable présentable à un autre cabinet, ce qui est le test décisif. Si le résultat n’a d’utilité qu’à condition de les engager, c’était un document commercial déguisé en livrable. Certains cabinets le facturent, d’autres en proposent une version gratuite : c’est notre cas, et c’est ainsi que commence chacune de nos missions. Payant ou gratuit importe moins que la forme : court, borné, avec un résultat qui survit à la relation.

C’est aussi le moyen le moins cher de découvrir qu’un cabinet ne vous convient pas, le nôtre compris. Appliquez cette liste correctement et vous conclurez peut-être qu’un autre partenaire convient mieux à votre projet que nous. Ce n’est pas un échec de la liste : c’est la liste qui fonctionne. Tout l’intérêt de commencer petit tient là. La conclusion, quelle qu’elle soit, vous coûte deux semaines au lieu de deux trimestres.

La version courte : ignorez le florilège et lisez le cabinet à travers son comportement. Le partenaire que vous cherchez ne chiffre qu’après avoir compris, sait dire ce qu’il refuse, met des ingénieurs en face de vous, montre un vrai document de transfert et structure la mission de sorte que partir soit facile. Car la manière dont un cabinet se comporte avant le contrat, pendant qu’il cherche encore à vous convaincre, est le plafond de son comportement après.

Questions fréquentes