Choisir une société de développement sans connaissances techniques
Que demander, ce que révèlent les réponses, et les signaux d'alerte visibles bien avant qu'une seule ligne de code soit écrite.
Vous vous apprêtez à dépenser une somme importante pour quelque chose que vous ne pouvez pas évaluer directement. C'est inconfortable, et la réaction habituelle — poser des questions sur les technologies — aggrave les choses, parce que les réponses sont invérifiables.
Vous n'avez pas besoin de juger la compétence technique. Vous devez juger si quelqu'un a compris votre problème, et s'il sera encore joignable dans un an. Les deux s'évaluent sans connaissances techniques.
Le signal qui compte le plus
Le prestataire pose-t-il plus de questions qu'il ne donne de réponses ?
Un prestataire qui répond à votre première description par un devis n'a pas compris le problème, parce que votre première description n'était pas complète — celle de personne ne l'est. Un bon prestataire passera le premier entretien à vous interroger sur votre processus, vos systèmes existants, les futurs utilisateurs, et ce qui se passe quand les choses tournent mal.
Le signal le plus fort : un prestataire qui, au bout de vingt minutes, vous reformule votre problème plus clairement que vous ne l'aviez exposé. C'est tout le test, et il fonctionne quel que soit votre bagage technique.
Sept questions, et ce que révèlent les réponses
« Pouvez-vous me montrer quelque chose de similaire que vous avez réalisé, et me dire ce qui s'est mal passé ? »
Tout le monde a un portfolio. Ce qui vous intéresse, c'est la seconde moitié de la question. Tout vrai projet a une partie difficile ; un prestataire incapable d'en citer une n'a pas livré grand-chose, ou n'est pas franc avec vous.
« Qui fera concrètement le travail ? »
Vous voulez des noms, et une raison de croire que ces personnes resteront sur le projet. Méfiez-vous de l'équipe senior présente au rendez-vous commercial, remplacée par une autre ensuite.
« À qui appartiendra le code ? »
La réponse doit être : à vous, sans réserve. Une hésitation sur ce point est le signal d'alerte le plus utile de cette liste — voir neuf points à vérifier dans un contrat.
« Que se passe-t-il après la mise en ligne ? »
Demandez précisément : qui corrige les défauts, pendant combien de temps, à quel coût, et dans quels délais. Un prestataire sans réponse claire n'a pas réfléchi au-delà de la facturation.
« De quoi avez-vous besoin de notre part ? »
Les bons prestataires sont exigeants. Il leur faut des décisions, des accès, et du temps de quelqu'un chez vous. Un prestataire qui répond « rien, laissez-nous faire » décrit un projet qui livrera quelque chose que vous ne vouliez pas.
« Qu'est-ce que vous refuseriez de développer pour nous ? »
Un prestataire prêt à dire « vous n'en avez pas besoin, achetez plutôt une solution existante » vaut davantage qu'un autre qui approuve tout. Si tout ce que vous proposez est une bonne idée, vous parlez à un processus commercial, pas à un ingénieur.
« Peut-on commencer par quelque chose de petit et de payant ? »
Le meilleur moyen de réduire le risque. Deux à quatre semaines, un périmètre serré, un vrai livrable. Cela coûte une fraction du projet et vous en apprend plus que n'importe quelle liste de références.
Signaux d'alerte
| Signal | Ce que cela signifie généralement |
|---|---|
| Un prix avant toute question | Il devine, et l'écart reviendra sous forme de demandes de modification |
| Refus de dire qui fera le travail | Sous-traité, ou pas encore recruté |
| Évasif sur la propriété du code | Vous serez captif |
| Aucun périmètre écrit | Chaque désaccord devient votre problème |
| « Nous pouvons commencer lundi » | Aucun projet en cours, ce qui est en soi une information |
| Dédaigneux envers vos systèmes existants | Il sous-estimera l'intégration, là où se trouve le coût |
| Ne parle que de technologies | Centré sur ce qui l'intéresse, pas sur ce dont vous avez besoin |
Bien vérifier les références
Demandez-en trois, dont une où les choses se sont mal passées. Un prestataire incapable d'en fournir une n'a pas d'historique, ou soigne l'image que vous vous faites de lui.
Quand vous parlez à une référence, évitez « étiez-vous satisfait ? » — personne ne répond non. Demandez plutôt :
- Qu'est-ce qui vous a surpris dans ce projet ?
- Qu'avez-vous dû faire que vous n'aviez pas prévu ?
- Si c'était à refaire, que changeriez-vous ?
- Sont-ils toujours réactifs aujourd'hui ?
C'est la dernière qui compte le plus. Bien des prestataires livrent correctement, puis disparaissent.
Ce que le prix vous dit vraiment
Pas grand-chose, à lui seul. Un grand écart entre devis signifie généralement que le cahier des charges autorisait plusieurs lectures, pas qu'un prestataire est malhonnête.
Harmonisez avant de comparer : même périmètre, même remise des livrables, même garantie, même hypothèse de maintenance, sur trois ans.
Le devis réellement le moins cher mérite une question : qu'est-ce qui manque ? Généralement l'interface d'administration, la gestion des erreurs, ou tout support après la mise en ligne.
Questions fréquentes
Grande entreprise ou petite équipe ?
Une petite équipe vous donne les personnes que vous avez rencontrées et des décisions plus rapides. Une structure plus grande vous assure la continuité si quelqu'un part. Pour la plupart des projets de moins de six mois, la petite équipe l'emporte sur le résultat ; au-delà, demandez franchement ce qui se passe si votre développeur principal s'en va.
Local ou à distance ?
Le fuseau horaire compte plus que la distance. Un prestataire à une ou deux heures de décalage partage votre journée de travail ; à huit heures d'écart, c'est une journée de retard sur chaque question. Les points à considérer sont dans le nearshoring en Égypte.
Faut-il d'abord rédiger un cahier des charges ?
Rédigez une page, pas un cahier des charges. Qui l'utilise, les trois choses qu'ils y font, avec quels systèmes il doit communiquer. Un prestataire incapable de travailler à partir de cette page — ou qui refuse de vous aider à en tirer un périmètre — n'est pas le bon prestataire.
Continuer la lecture
Newsletter
Des notes occasionnelles sur le logiciel, l'automatisation et une meilleure gestion d'entreprise. Pas de spam.