On reçoit souvent des appels de fondateurs ou de gestionnaires qui ont déjà travaillé avec un développeur ou une agence, et ça s'est mal passé. Délais non respectés, coûts qui explosent, code qui ne peut pas évoluer. Ce n'est pas une fatalité.
Choisir le bon partenaire technologique, ça s'apprend. Voici ce qu'on regarde nous-mêmes quand on évalue nos propres pratiques, et ce que vous devriez regarder quand vous magasinez.
La première rencontre en dit beaucoup
Avant même de parler de technologie ou de prix, observez comment le développeur ou l'agence réagit à votre première description du projet.
Est-ce qu'il pose des questions sur votre clientèle, vos objectifs, vos contraintes ? Ou est-ce qu'il commence immédiatement à parler de frameworks et d'architectures ?
Un bon partenaire cherche d'abord à comprendre le problème. Il reformule votre vision pour vous montrer qu'il a saisi l'essentiel. Si vous sortez du premier appel avec l'impression que l'autre côté a compris ce que vous voulez bâtir, c'est un bon signe.
💬 Ce qu'on veut entendre lors du premier appel
"Parlez-moi de vos utilisateurs. Quel problème essayez-vous de régler pour eux ? Qu'est-ce qui se passe aujourd'hui si ce problème n'est pas résolu ?" Un développeur qui commence par ces questions pense comme un partenaire, pas comme un sous-traitant.
Freelance, petite agence ou grande firme ?
Ce n'est pas une question de prestige ou de budget. C'est une question de risque et de besoin. Voici comment on voit les trois options :
| Freelance | Petite agence | Grande firme | |
|---|---|---|---|
| Coût | Plus bas | Moyen | Élevé |
| Expertise | Souvent une spécialité | Pluridisciplinaire | Large, mais fragmentée |
| Disponibilité | Variable | Dédiée | Partagée entre projets |
| Risque de départ | Élevé | Faible | Faible |
| Idéal pour | MVP simple, court terme | Projets évolutifs, PME | Grands comptes, budgets importants |
Aucune option n'est universellement meilleure. Tout dépend de la complexité de votre projet et du niveau de risque que vous êtes prêt à absorber.
Demandez à voir du vrai travail, pas juste des logos clients
Tout le monde a une belle page de clients sur son site. Ce qui compte, c'est de voir comment ce travail a été fait.
Demandez des exemples de fonctionnalités similaires à ce que vous voulez construire. Demandez si vous pouvez parler à un ancien client. Regardez si les projets montrés ressemblent à votre contexte (taille, industrie, complexité).
- ✓"Pouvez-vous me montrer une fonctionnalité similaire à ce que je veux construire ?"
- ✓"Est-ce que je peux parler à un de vos anciens clients ?"
- ✓"Avez-vous travaillé dans mon industrie ou sur des projets de cette taille ?"
- ✓"Comment gérez-vous les changements de scope en cours de projet ?"
- ✓"Qui sera mon interlocuteur principal au jour le jour ?"
Le processus compte autant que les compétences techniques
Un bon développeur peut produire du mauvais travail si le processus est chaotique. Voici les indicateurs qu'on considère comme non-négociables :
- ✓Des livrables réguliers. Quelque chose de fonctionnel toutes les deux semaines, pas juste un rapport verbal.
- ✓Une gestion transparente des priorités. Vous devriez être le premier informé quand un délai change ou qu'un problème survient.
- ✓Des outils de suivi accessibles. Jira, ClickUp, Notion... peu importe, tant que vous avez accès à l'état du projet en tout temps.
- ✓Des revues de code régulières. Le code est relu par quelqu'un d'autre que celui qui l'a écrit.
Les signaux d'alarme à surveiller
Certains comportements sont des avertissements clairs. Si vous en repérez plus d'un, prenez le temps d'y réfléchir avant de signer quoi que ce soit.
- ✕Il dit oui à tout, sans poser de questions, sans émettre de réserves.
- ✕Le devis arrive en quelques heures, sans analyse sérieuse du projet.
- ✕Pas de contrat clair sur la propriété du code après livraison.
- ✕Il ne peut pas expliquer ses choix technologiques en termes simples.
- ✕Les références clients sont vagues ou introuvables.
- ✕Il refuse de faire une phase de découverte avant de coder.
La sécurité, ce n'est pas une option
On voit encore beaucoup de projets livrés sans tests, sans revue de code, avec des mots de passe stockés en clair ou des dépendances jamais mises à jour.
Demandez comment les données de vos utilisateurs sont protégées. Comment les accès sont gérés. Si le développeur n'a pas de réponse claire, c'est une réponse en soi.
⚠️ Ne pas négliger la sécurité
Une fuite de données peut coûter bien plus cher que le développement initial. Vérifiez que votre partenaire parle de sécurité dès la phase de conception, pas seulement à la fin.
Et après le lancement ?
Un logiciel, ce n'est pas un projet avec une date de fin. C'est un actif qui doit être maintenu, amélioré, mis à jour.
Si votre partenaire ne parle pas de support post-lancement, posez la question directement. Et si la réponse est floue, prenez-en note.
- ✓Qui s'occupe des bogues après la mise en ligne ?
- ✓Qui gère les mises à jour de sécurité ?
- ✓Quel est le délai de réponse si quelque chose tombe en panne ?
- ✓Comment se passe l'ajout d'une nouvelle fonctionnalité dans six mois ?
Ce qu'on vous dit rarement
La compatibilité humaine compte. Vous allez travailler avec cette équipe pendant des mois. Si la communication est difficile dès le départ, ça ne s'améliore pas avec le temps.
💡 Un bon partenaire vous dit non
Choisissez quelqu'un avec qui vous pouvez avoir une conversation honnête. Un partenaire qui vous dit "votre idée a un problème ici" est beaucoup plus précieux qu'un partenaire qui dit oui à tout. Le oui facile, ça se paie toujours plus tard.
