Comment choisir une entreprise de développement logiciel quand on ne sait pas lire le code

Un guide pour les fondateurs non techniques : les signaux qui prédisent vraiment si votre projet va sortir, les critères qui paraissent importants et ne le sont pas, et les quatre questions à poser avant de signer quoi que ce soit.

Vous avez fait trois rendez-vous commerciaux cette semaine. Les trois entreprises étaient chaleureuses, professionnelles et sûres d’elles. Les trois ont dit que votre projet était tout à fait faisable. Les trois ont envoyé un deck avec un mur de logos, une note de cinq étoiles sur Clutch et un portfolio d’applis qui ressemblaient à la vôtre. Vendredi, vous aviez trois propositions sur le bureau, deux à moins de 15 % d’écart de prix, et aucune idée réelle de comment choisir.

C’est la partie difficile du choix d’une entreprise de développement logiciel : les éléments que vous pouvez voir sont ceux que chaque prestataire a appris à polir, et l’élément qui compte le plus, à savoir s’ils vont vraiment livrer un logiciel qui marche et que vous n’aurez pas à surveiller, reste invisible jusqu’à ce que vous ayez déjà payé. Alors la réponse courte est celle-ci. On choisit une entreprise de développement logiciel sur la façon dont elle se comporte avant que l’argent ne change de mains, pas sur ce qu’elle vous montre. Comment elle cadre le travail, comment elle conteste vos idées, comment elle parle de coût et de risque, et ce qu’elle fait quand vous lui posez une question à laquelle elle ne sait pas répondre clairement. Ces quatre comportements prédisent la livraison. Le portfolio, non.

On peut le dire parce qu’on est une entreprise de développement logiciel. Ce qui suit est le guide de l’acheteur écrit depuis l’intérieur de la salle, y compris les passages que notre propre secteur préférerait ne pas publier, parce que la moitié de ce qui passe pour un processus commercial finit sur la liste des signaux d’alerte.

Le piège dans lequel tous les autres guides vous emmènent

Cherchez cette question et vous trouverez une douzaine d’articles, presque tous écrits par des entreprises de logiciel, qui vous disent d’évaluer trois choses : portfolio, expertise technique et prix. Ce conseil n’est pas tant faux qu’inutile, parce que les trois sont faciles à maquiller et qu’aucun ne survit au contact de votre vrai projet.

Un portfolio montre le travail dont l’entreprise est la plus fière, capturé à son meilleur moment, sans aucune mention des projets livrés avec six mois de retard ou refaits par le prestataire suivant. « Expertise technique », c’est une liste de logos : React, AWS, Python, Kubernetes. Chaque entreprise de votre shortlist a la même liste, et vous n’avez aucun moyen de savoir si elle utilise ces outils correctement ou si elle sait juste les épeler. Et le prix, le seul chiffre que vous vous sentez capable de comparer, est l’élément le plus trompeur de tous, pour des raisons qu’on verra plus loin.

Le problème de fond, c’est que ce modèle vous demande de juger une entreprise sur des artefacts. Un fondateur non technique ne peut pas juger un artefact logiciel de façon fiable. Vous ne lisez pas le code, vous ne distinguez pas une architecture propre d’une architecture fragile, et vous ne savez pas si cette superbe appli du portfolio est maintenable en dessous ou tenue avec du scotch. Si votre méthode de choix exige d’évaluer des choses que vous ne pouvez pas voir, vous n’avez pas de méthode. Vous avez un pile ou face avec des étapes en plus.

Alors arrêtez d’essayer de noter le logiciel. Notez le comportement. Le comportement, un fondateur non technique le lit très bien, parce qu’il apparaît en langage clair, en réunion, dans la façon dont les questions reçoivent leurs réponses. Et le comportement avant le contrat est le meilleur prédicteur disponible du comportement après.

Ce qui prédit vraiment si votre projet va sortir

Quatre comportements, observables dès les deux premières conversations, en disent plus que n’importe quel portfolio.

Comment ils cadrent votre projet. Confiez la même idée vague à deux entreprises. L’une revient avec un devis. L’autre revient avec des questions : qui est l’utilisateur, que se passe-t-il quand ça tourne mal, à quoi ça se connecte, quelle est la seule fonctionnalité qui doit marcher dès le premier jour. La deuxième entreprise est plus pénible à gérer la première semaine et bien moins coûteuse au sixième mois. Les exigences floues, c’est là que les projets logiciels meurent, et le travail de définir le périmètre avant d’embaucher qui que ce soit est exactement ce qu’une bonne entreprise exige. Un studio qui prend votre brief à moitié ficelé et vous chiffre aussitôt vous prévient qu’il construira ce que vous direz et vous facturera les reprises. La manière dont un studio cadre est un avant-goût de la manière dont il mènera le projet. Un bon studio traite le cadrage comme le travail le plus important, pas comme une formalité avant le vrai travail.

Comment ils vous contredisent. Observez ce qui se passe quand vous proposez une mauvaise idée. Tout fondateur en propose quelques-unes. Vous demandez une fonctionnalité qui double le délai et ne sert personne, ou vous décrivez une architecture entendue dans un podcast. Un prestataire qui optimise pour la vente acquiesce et l’ajoute au devis. Un partenaire vous dit que c’est une mauvaise idée et explique pourquoi, même si vous contredire est le coup commercial le plus risqué. La volonté de perdre un peu de sympathie pour vous épargner de l’argent est le signal le plus sous-estimé de cette liste. Une entreprise qui ne vous dit pas non avant que vous payiez ne vous dira jamais non après, et un projet où personne ne dit non est un projet qui gonfle. C’est la différence entre un partenaire technique et une boîte noire : un partenaire discute avec vous.

Comment ils parlent de coût et d’incertitude. Demandez combien de temps ça prendra et combien ça coûtera. La réponse honnête comporte une fourchette, quelques hypothèses et l’aveu que le chiffre bougera à mesure que vous apprendrez. La réponse conçue pour gagner le contrat est un montant unique et assuré, sans nuance. Estimer du logiciel est réellement difficile, et une entreprise qui prétend que c’est facile est soit inexpérimentée, soit en train de vous mentir pour vous closer. Steve McConnell, auteur de Code Complete, a consacré sa carrière à un seul point : les estimations précoces portent une incertitude énorme. Un studio qui respecte cette incertitude à voix haute gérera votre budget honnêtement. Un studio qui l’enterre la découvrira plus tard, sur votre facture.

Ce qu’ils font quand ils ne savent pas. Posez une question un peu hors de leur zone de confort. Regardez s’ils disent « je ne sais pas, je vérifie » ou s’ils sortent une réponse assurée sur-le-champ. La phrase « je ne suis pas sûr, je me renseigne » est l’une des choses les plus rassurantes qu’un prestataire puisse dire, parce qu’elle montre qu’il distingue ce qu’il sait de ce qu’il devine, et cette distinction, c’est tout le métier. Les gens que vous embauchez vont passer des années à prendre des décisions que vous ne pouvez pas vérifier. Vous ne pariez pas sur le fait qu’ils ont toutes les réponses. Vous pariez sur le fait qu’ils seront honnêtes sur les réponses qu’ils n’ont pas.

Les critères qui paraissent importants et ne le sont pas

Certains des éléments qu’on vous a dit de peser lourdement ne méritent presque aucun poids.

Le mur de logos. Des clients prestigieux signifient qu’une entreprise sait décrocher des clients prestigieux. Cela ne dit rien sur le fait que votre projet, plus petit et moins prestigieux, recevra ses profils seniors ou son banc de touche. Parfois, le logo célèbre est même un avertissement : vous serez le compte qui hérite de l’équipe junior pendant que les meilleurs servent la grande marque.

Prix et badges d’annuaire. Une bonne note sur un annuaire de prestataires dépend du nombre de clients satisfaits à qui l’entreprise a demandé de laisser un avis, et, dans certains cas, de ce qu’elle dépense auprès de l’annuaire lui-même. C’est une sortie marketing, pas une mesure de qualité. Traitez-la comme un autocollant « Meilleur de » sur la vitrine d’un restaurant : faiblement positif, facile à truquer, et pas une raison de choisir.

La taille de l’équipe. Une entreprise de 200 personnes n’est pas plus sûre qu’un studio de 12. Les grandes maisons offrent du process et de la continuité et, souvent, plus de couches entre vous et ceux qui écrivent réellement votre code. Les petites offrent un accès direct et de l’attention senior et, souvent, plus de risque de dépendance à une personne. Aucune des deux n’est la bonne réponse. La bonne taille dépend de votre projet, et une entreprise qui vous dit que plus grand est toujours plus sûr vend son propre effectif.

Le pitch de la stack. Si une entreprise commence par vous dire à quel point sa stack est moderne et inédite, méfiez-vous. Les outils ennuyeux et éprouvés sont en général le bon choix pour un produit à ses débuts, et un studio qui court après le framework le plus récent résout parfois le CV de ses ingénieurs, pas votre maintenabilité. Vous voulez une entreprise qui choisit la technologie selon votre problème, pas selon la tendance. On a déjà écrit sur la différence entre la tech émergente comme outil et comme religion dans notre article sur l’audit de code ; le même test s’applique au moment de choisir qui construit.

Le 80/20 du choix d’une entreprise de développement logiciel

Il existe une version du principe de Pareto qui colle bien à cette décision : une petite part des signaux porte l’essentiel du poids prédictif. Si vous n’aviez le temps d’évaluer que deux choses, évaluez celles-ci.

D’abord, comment ils gèrent l’écart entre ce que vous avez demandé et ce dont vous avez réellement besoin. Les meilleures entreprises passent la première conversation à resserrer votre projet, pas à le gonfler. Elles trouvent la version de votre idée qui coûte la moitié et teste le même risque. Un prestataire qui ne fait qu’ajouter du périmètre optimise pour sa facture. Un partenaire qui retranche du périmètre optimise pour votre résultat, et cette orientation, une fois que vous la voyez, est difficile à feindre.

Ensuite, comment un vrai client à eux répond à une question précise. Ne demandez pas à leurs références si elles étaient contentes. Tout le monde dit oui. Demandez : « Qu’est-ce qui s’est mal passé, et comment l’ont-ils géré ? » Tout vrai projet a une mauvaise semaine. La référence qui sait décrire un problème et un redressement décrit une entreprise qui dit la vérité sous pression. La référence qui insiste sur le fait que rien n’a jamais mal tourné, soit n’a jamais livré quelque chose de difficile, soit n’est pas franche. Cette seule question fait plus de travail que tout le reste de l’appel réuni.

Les quatre questions à poser au premier rendez-vous

Apportez-les à la première conversation. Les réponses, et l’aisance avec laquelle elles sont données, trieront votre shortlist vite.

« Racontez-moi un projet qui a dérapé et ce que vous avez fait. » Vous testez l’honnêteté et le fait qu’ils aient livré quelque chose d’assez difficile pour déraper.

« Si vous deviez couper mon périmètre de moitié pour tenir le budget, que couperiez-vous et pourquoi ? » Vous testez s’ils comprennent assez votre produit pour avoir un avis sur son cœur, et s’ils raisonnent en arbitrages plutôt que de tout vous vendre.

« Qui précisément va travailler là-dessus, et que se passe-t-il si cette personne part ? » Vous testez le risque de dépendance à une personne et le fait de recevoir l’équipe du pitch ou une autre, moins chère, après signature. Dépendre d’un seul développeur est un coût réel, et une entreprise sérieuse a une réponse pour ça.

« Comment saurai-je que le projet déraille avant qu’il soit trop tard pour le rattraper ? » Vous testez s’ils rendront le travail visible pour un propriétaire non technique, ou si vous resterez aveugle jusqu’à ce qu’une échéance tombe. La réponse devrait inclure quelque chose que vous pouvez réellement voir chaque semaine, pas une couleur de statut dans un outil que vous n’ouvrez pas.

Une entreprise qui répond à ces quatre questions proprement, sans se hérisser, a probablement déjà eu ces conversations et y a survécu. C’est l’essentiel de ce que vous cherchez.

Moins cher est un signal, pas une économie

Le devis qui arrive 40 % en dessous des autres n’est pas une remise. C’est une information. Soit cette entreprise a cadré votre projet plus superficiellement que les autres, et l’écart réapparaîtra en avenants une fois que vous serez engagé, soit elle compte affecter à votre construction des profils moins chers et moins expérimentés, soit elle ne comprend pas encore assez le travail pour le chiffrer. De temps en temps, un devis bas reflète une efficacité réelle. Le plus souvent, il reflète un malentendu que vous paierez pour corriger.

Le devis cher n’a pas automatiquement raison non plus. Mais quand les prix divergent fortement, la bonne réaction n’est pas de prendre le moins cher. C’est de demander à chaque entreprise d’expliquer son chiffre, parce que l’explication vous dit qui a vraiment compris le projet. Le prix est plus utile comme question que comme réponse. On détaille la version plus poussée de tout ça dans notre article sur la façon dont les projets externalisés sont chiffrés et où se cachent les surprises.

Comment vérifier ce que vous ne pouvez pas lire vous-même

Vous ne savez toujours pas lire le code. Alors intégrez la vérification à la mission au lieu d’essayer de la faire pendant le processus commercial.

Commencez par une petite tranche de vrai travail, payée et cadrée, avant de vous engager sur toute la construction. Un sprint de discovery, une première fonctionnalité, une tranche fonctionnelle du vrai produit. Un mois de collaboration réelle en apprend plus sur une entreprise que dix heures d’appels, et c’est une assurance bon marché contre une erreur de six mois. Leur comportement à l’intérieur de cette petite mission, s’ils communiquent, s’ils tiennent ce qu’ils avaient annoncé, si le logiciel qui tourne correspond à la démo, c’est ce qui se rapproche le plus d’une garantie que vous obtiendrez.

Ensuite, avant de passer à l’échelle ou à chaque grand jalon, vous pouvez faire examiner ce qui a été construit par quelqu’un d’indépendant. Pas besoin de savoir lire le code pour commander un audit de code et obtenir, en langage clair, un avis sur la solidité des fondations. Une entreprise confiante accueille bien ce deuxième regard. Une entreprise nerveuse y résiste, et la résistance est sa propre réponse.

Choisir une entreprise de développement logiciel ne sera jamais une valeur sûre, parce que vous achetez quelque chose que vous ne pouvez pas inspecter entièrement à quelqu’un que vous venez de rencontrer. Mais vous pouvez arrêter d’essayer de noter le logiciel et commencer à noter les gens, au grand jour, avant d’avoir dépensé un euro. L’entreprise qui cadre avec soin, vous contredit, chiffre honnêtement et admet ce qu’elle ne sait pas, c’est celle qui livre. Tout le reste n’est qu’un mur de logos.

Foire aux questions

Comment choisir la bonne entreprise de développement logiciel quand on n’est pas technique ?
Jugez le comportement, pas les artefacts. Vous ne pouvez pas évaluer le code, l’architecture ou un portfolio soigné, mais vous pouvez évaluer comment une entreprise cadre votre projet, si elle conteste les mauvaises idées, avec quelle honnêteté elle parle de coût et d’incertitude, et ce qu’elle fait quand elle ignore une réponse. Ces comportements apparaissent en conversation claire et prédisent la livraison mieux que n’importe quel titre technique. Réduisez ensuite le risque en commençant par une petite mission payée avant de vous engager sur toute la construction.

Quelle est la règle des 80/20 pour choisir une entreprise de logiciel ?
Un petit ensemble de signaux porte l’essentiel du poids prédictif. Les deux qui comptent le plus : l’entreprise resserre-t-elle votre périmètre (en optimisant pour votre résultat) ou ne fait-elle que le gonfler (en optimisant pour sa facture), et comment une vraie référence répond-elle à « qu’est-ce qui s’est mal passé et comment l’ont-ils géré ». Ces deux questions en disent plus que les portfolios, les prix et les récompenses réunis.

Quelles questions poser à une entreprise de développement logiciel avant de l’engager ?
Quatre : racontez-moi un projet qui a dérapé et ce que vous avez fait ; si vous deviez couper mon périmètre de moitié, que couperiez-vous et pourquoi ; qui précisément va travailler là-dessus et que se passe-t-il s’il part ; et comment saurai-je que le projet déraille avant qu’il soit trop tard. Vous testez l’honnêteté, la compréhension du cœur de votre produit, le risque de dépendance à une personne, et le fait que le travail vous soit visible.

Un devis moins cher signifie-t-il une qualité moindre ?
Pas toujours, mais un devis bien en dessous des autres est une information, pas une économie. Il signifie en général un cadrage plus superficiel, des profils moins chers ou un malentendu sur le travail, et l’écart tend à réapparaître plus tard en avenants. Quand les prix divergent fortement, demandez à chaque entreprise d’expliquer son chiffre. L’explication révèle qui a vraiment compris le projet.

À combien d’entreprises de développement logiciel devrais-je parler ?
Assez pour trianguler, en général trois à cinq. Une seule ne vous donne aucun repère. Une douzaine fait perdre du temps à tout le monde et tend à se réduire à une comparaison de prix, l’axe le moins utile. Trois à cinq vous permettent de comparer à quel point chacune cadre différemment le même brief, et c’est la comparaison qui compte.

Faut-il choisir une grande agence ou un petit studio ?
Aucun n’est plus sûr par défaut. Les grandes maisons offrent du process et de la continuité mais plus de distance avec ceux qui écrivent votre code ; les petits studios offrent de l’attention senior et un accès direct mais plus de risque de dépendance à une personne. La bonne taille dépend de la complexité de votre projet et du niveau d’accompagnement dont vous avez besoin. Méfiez-vous de toute entreprise qui vous dit que sa propre taille est automatiquement le choix sûr.