Comment choisir une société de développement logiciel

Nous sommes l'une des sociétés que vous évaluez peut-être, ce qui rend cet article intéressé par construction. Le correctif consiste à inclure les questions qui nous dérangent, et à dire explicitement où une structure plus grande ou un indépendant vous servirait mieux. Jugez l'article sur sa tenue lorsqu'on l'applique à nous.

Ce que testent la plupart des processus de sélection, et pourquoi cela échoue

Le processus habituel compare des réalisations, la taille de l'équipe, des listes de technologies et un prix. Rien de tout cela ne prédit grand-chose.

Les réalisations montrent ce qui a été livré, pas si c'était dans les délais, si le client rachèterait, ni si cela fonctionne encore. Les captures d'écran sont la partie la plus facile à produire d'un projet et la moins corrélée à la réussite.

La taille de l'équipe prédit la capacité, pas la qualité, et au-delà d'un certain point elle prédit le coût de coordination. Les listes de technologies sont presque dénuées de sens — chaque agence liste toutes les technologies, et ce qui compte est de savoir si les personnes précises sur votre projet connaissent bien la pile précise.

Le prix, nous l'avons traité ailleurs. En résumé, le devis le plus bas est en général le moins complet.

Les questions qui prédisent vraiment le résultat

1. Pouvez-vous nous décrire notre métier ?Posez cette question à la fin de la première conversation. Un prestataire qui a compris le problème peut le reformuler dans ses propres mots, y compris la partie qui le rend délicat. Celui qui ne le peut pas construira ce que vous avez dit littéralement, ce qui n'est jamais tout à fait ce que vous vouliez dire.
2. Qu'est-ce qui vous ferait refuser ce projet ?Quiconque s'est brûlé a une réponse : aucun responsable interne, une échéance fixée avant le périmètre, un client qui ne décide pas. Un prestataire sans critère de refus a soit eu de la chance, soit n'est pas franc avec vous.
3. Qui écrira cela précisément, et sur quoi d'autre travaille cette personne ?Les personnes présentes à la présentation ne sont souvent pas celles du projet. Demandez des noms et leurs engagements en cours. Cette seule question élimine toute une catégorie de déceptions.
4. Montrez-nous une erreur que vous avez commise et ce que vous avez changé.Tout projet réel en comporte une. Une réponse précise, technique et légèrement inconfortable montre qu'ils réfléchissent à leur travail. Une réponse polie sur « la communication » montre qu'ils ont préparé cette question et rien d'autre.
5. Qu'advient-il du code et des comptes si nous nous séparons ?La réponse doit être structurelle : le dépôt est à vous, le déploiement est documenté, la pile est courante, vos comptes cloud et vos comptes de stores sont à votre nom. Si quoi que ce soit de cela est détenu par le prestataire, vous achetez une dépendance et non un logiciel.
6. Comment saurons-nous que cela tourne mal, et quand ?Les bons prestataires ont un mécanisme — du logiciel qui tourne à cadence fixe, une démonstration à laquelle vous assistez, un reste-à-faire que vous pouvez lire. Si la première visibilité réelle est à la livraison, le risque est entièrement chez vous et vous l'apprendrez trop tard.

Les signaux qui justifient de renoncer

• Un devis qui arrive sans aucune question sur vos données. Le coût réside dans le modèle de données ; un chiffre produit sans l'avoir demandé a été produit sans y avoir réfléchi.
• Un accord sur tout. Un prestataire qui ne conteste jamais soit n'écoute pas, soit prévoit de facturer la reprise.
• Aucune mention de migration, de tests ou de fonctionnement en parallèle. Ce travail existe qu'il soit chiffré ou non, et s'il manque au devis il reviendra sous forme d'avenant.
• Une démonstration sur laquelle on ne peut pas cliquer. Si la seule preuve consiste en captures d'écran et une vidéo, demandez l'accès à quelque chose de réel. S'il n'est pas proposé, il y a une raison.
• Une pression à signer avant le cadrage. Le cadrage est le moment où les deux parties découvrent si le projet est bien ce qu'elles croient. L'escamoter ne profite à personne, sauf à un prestataire qui soupçonne la réponse.
• Une réticence à nommer les personnes qui feront le travail, ou à vous laisser leur parler.

Quand un studio est le mauvais choix

Nous sommes un petit studio. Cela convient aux projets où la valeur réside dans une bonne compréhension du domaine, où vous voulez que ceux qui l'ont conçu le construisent, et où l'accès direct aux ingénieurs compte plus que le poids du processus. C'est la mauvaise forme pour plusieurs situations, et le dire coûte moins cher à tout le monde que de le découvrir au quatrième mois.

S'il vous faut cent personnes sur le terrain pour un programme de deux ans, il vous faut un intégrateur de systèmes, et ce qui fait la qualité d'un petit studio n'a aucune pertinence à cette échelle.

Si le travail est une tâche courte, bien définie et autonome — un thème WordPress, un site d'une page, un petit script — un indépendant compétent le fera plus vite et moins cher, et vous ne devriez pas payer les frais d'un studio pour cela.

Si votre organisation exige une assistance nommée 24h/24 avec des délais de réponse contractuels et une procédure d'escalade formelle, demandez directement ce qui est réellement fourni plutôt que d'accepter une assurance verbale. C'est un besoin réel et les petites équipes ne peuvent souvent pas y répondre honnêtement.

Vérifier correctement les références

Les appels de référence sont généralement perdus, parce que les questions appellent une réponse positive. « Étiez-vous satisfait ? » obtient « oui » de presque tout le monde, y compris de ceux qui ne rachèteraient pas.

Demandez plutôt : quel a été le plus grand désaccord et comment il a été résolu ; combien le projet a coûté par rapport à la première estimation, et pourquoi ; ce que vous avez dû faire sans l'avoir prévu ; et si vous feriez de nouveau appel à eux pour quelque chose de plus gros. C'est sur cette dernière question que l'hésitation est instructive.

Demandez une référence dans votre secteur si le prestataire revendique une expérience sectorielle, et interrogez un client dont le projet est terminé depuis au moins un an. Les clients récents sont encore dans l'euphorie. Un an après, ils savent si le logiciel fonctionne encore et si les évolutions restent possibles.

Ce qui prédit le mieux la réussite

Pas le prestataire. Mais le fait que votre côté ait une personne ayant l'autorité de décider et le temps de s'impliquer. Les projets avec un vrai responsable réussissent avec des prestataires moyens ; ceux qui n'en ont pas échouent avec d'excellents prestataires, parce que chaque décision devient un comité et chaque ambiguïté un retard.

Si vous ne pouvez pas nommer cette personne ni protéger son temps, réglez cela avant de sélectionner qui que ce soit. Cela changera le résultat plus que n'importe quel choix de cette liste.