Vous cherchez une entreprise de développement informatique. Vous faites ce que tout le monde fait : vous comparez les devis, vous parcourez les portfolios, vous essayez de comprendre pourquoi l'un est deux fois plus cher que l'autre pour un projet qui semble identique.
Sauf que les projets qui échouent, dans notre expérience, n'échouent quasiment jamais à cause du prix. Ni à cause d'un mauvais choix de technologie, d'ailleurs. Ils échouent parce que le prestataire n'a pas compris le vrai besoin, parce que le client n'a rien vu pendant quatre mois, ou parce qu'au moment de changer de prestataire, personne ne pouvait reprendre le code.
Chez Dorima, nous développons des logiciels sur-mesure depuis plus de dix ans. Plus de 150 projets livrés, pour des entreprises de 5 comme de 500 personnes. Nous avons vu des projets très bien se passer, et nous avons accompagné de nombreux clients qui arrivaient d'une première expérience difficile ailleurs. À force, nous avons fini par identifier les critères qui font vraiment la différence. Aucun ne figure dans un devis.
Ce qui suit, c'est ce que nous conseillerions à un proche qui s'apprête à choisir son prestataire. Y compris si ce prestataire, c'est nous.
Est-ce que l'équipe comprend votre métier, pas juste la technique ? 🔍
Le critère le plus sous-estimé, de loin.
Une équipe peut être excellente techniquement et livrer un produit que personne n'utilise. Nous l'avons vu. Le logiciel tourne, il est rapide, le code est propre. Mais il ne correspond pas à la réalité du terrain parce que personne dans l'équipe n'a pris le temps de comprendre comment les gens travaillent au quotidien.
Autrement dit, l'équipe a construit ce qu'on lui a demandé. Pas ce dont le client avait besoin. Ce n'est pas la même chose.
Un bon prestataire ne se contente pas de prendre la commande. Il cherche à comprendre le problème derrière la demande.
Les premiers échanges vous disent beaucoup
Regardez les questions qu'un prestataire vous pose au tout début. Est-ce qu'il vous demande tout de suite combien de pages vous voulez, quelles fonctionnalités, quel budget ? Ou est-ce qu'il commence par s'intéresser à votre activité, à vos clients, à ce qui coince aujourd'hui dans votre fonctionnement ?
Un prestataire qui cherche d'abord à comprendre votre métier va challenger certaines de vos demandes. C'est bon signe. Un regard extérieur combiné à de l'expérience technique permet souvent de trouver des solutions plus simples que ce qu'on avait en tête au départ.
En revanche, un prestataire qui dit oui à tout, qui prend votre liste de fonctionnalités et vous renvoie un chiffrage en 48 heures sans avoir posé une seule question de fond... ce n'est pas de l'efficacité. C'est le signe que votre projet sera traité comme une commande, pas comme un problème à résoudre.
La question à poser
Demandez-leur de vous raconter un projet récent dans votre secteur ou un secteur proche. Comment ils ont abordé la compréhension du besoin, ce qu'ils ont découvert en cours de route, ce qui a changé par rapport à la demande initiale. Si la réponse reste floue ou 100% technique, la compréhension métier n'est pas leur priorité.
Est-ce que vous allez voir votre projet avancer, ou attendre dans le noir ? ⏳
Nous voyons régulièrement le même scénario. Un client signe avec une entreprise de développement informatique. On lui annonce une livraison dans six mois. Les premières semaines, quelques emails. Puis silence. Il relance, on lui dit que tout avance bien. Il demande à voir, on lui répond que ce n'est pas encore montrable. Au bout de cinq mois, on lui présente une version du produit. Qui ne correspond pas du tout à ce qu'il avait en tête.
C'est l'effet tunnel. Et c'est l'une des raisons les plus fréquentes pour lesquelles un projet de développement finit mal.
Ce n'est pas forcément de la mauvaise volonté
Certaines entreprises fonctionnent comme ça : on développe tout, on livre à la fin. C'est plus simple à gérer de leur côté. Mais pour vous, c'est un risque. Pendant ces mois de silence, l'équipe construit sur sa propre compréhension de votre besoin. Qui n'est jamais exactement la vôtre, même avec le meilleur cahier des charges du monde.
Les petits malentendus s'empilent. Et plus ils s'empilent longtemps sans être corrigés, plus ils coûtent cher à corriger.
Si on ne vous montre rien de fonctionnel dans les deux premiers mois, c'est un signal d'alerte.
Ce que vous devez exiger
Posez la question avant de signer : à quelle fréquence allez-vous me montrer ce qui a été développé ? Et par "montrer", on ne parle pas d'un compte-rendu par email ou d'une présentation PowerPoint. On parle de se connecter à une version du produit, même incomplète, et de cliquer soi-même.
Un bon prestataire vous montre quelque chose de fonctionnel toutes les deux à trois semaines. Pas un produit fini, un prototype en cours. Que vous pouvez tester, critiquer, réorienter.
Si on ne vous propose rien de concret dans les six à huit premières semaines, posez-vous des questions. Si on ne vous le propose pas du tout, cherchez ailleurs.
La question à poser
"Concrètement, c'est quoi le suivi côté client ? J'aurai accès à une version de test ? À quelle fréquence ?" Simple, mais les réponses en disent long.
Que se passe-t-il si vous voulez partir ? 🔓
La question que personne ne pose au moment de signer. Et probablement celle qui devrait venir en premier.
Quand vous faites développer un logiciel sur-mesure, vous investissez souvent plusieurs dizaines de milliers d'euros. Cet investissement produit quelque chose de concret : du code, une application, une base de données. Mais à qui appartient tout cela le jour où la relation se termine ?
Vérifiez la propriété intellectuelle dans le contrat
Dans beaucoup de contrats, la question de la propriété du code est floue. Quand elle n'est pas simplement absente. Certains prestataires gardent la propriété et vous accordent un droit d'usage. D'autres vous cèdent la propriété mais contrôlent l'hébergement. D'autres utilisent des briques logicielles maison qui vous rendent dépendant d'eux pour la moindre évolution.
Le code développé pour vous doit vous appartenir. C'est votre investissement, c'est votre outil de travail. Lisez les clauses avant de signer.
La vraie question : pourriez-vous changer de prestataire demain ?
Au-delà du contrat, il y a la réalité technique. Imaginons que dans deux ans, vous vouliez changer de prestataire. Le nouveau pourra-t-il reprendre le code et le faire évoluer ? Ou devra-t-il repartir de zéro parce que rien n'est documenté, le code est mal organisé, ou il repose sur des outils que seul le prestataire d'origine connaît ?
Un code bien écrit et documenté, c'est un code qui vous laisse libre. Un code opaque qui dépend d'un seul prestataire, c'est une prison — même si elle est confortable.
Le vrai test de la relation avec votre prestataire, c'est la facilité avec laquelle vous pourriez le quitter.
Les questions concrètes
Avant de signer, vérifiez ces points :
- Est-ce que j'aurai accès au code source en permanence ?
- La documentation technique fait-elle partie de la prestation ?
- Le code repose-t-il sur des technologies ouvertes et courantes, ou sur des outils propriétaires ?
- Y a-t-il une clause de réversibilité dans le contrat ?
Un prestataire sérieux n'aura aucun mal à répondre. En général, il aura anticipé la question.
Les certifications et labels : lesquels comptent vraiment 🏷️
En parcourant les sites d'entreprises de développement informatique, vous verrez des logos de certifications un peu partout. Certains engagent concrètement l'entreprise. D'autres sont là pour meubler la page "À propos". Comment faire la différence ?
Trois labels qui ont un impact concret
Le Crédit d'Impôt Innovation (CII) est un agrément délivré par le Ministère de l'Enseignement Supérieur et de la Recherche. Si votre prestataire est agréé, vous pouvez bénéficier d'un crédit d'impôt de 30% sur les dépenses d'innovation. Ce n'est pas un logo sur un site, c'est un avantage financier direct pour votre entreprise.
La certification Opquast atteste que les développeurs ont été formés et évalués individuellement sur les bonnes pratiques de qualité web : accessibilité, performance, sécurité. C'est un examen, pas un badge qu'on achète.
Le RGESN (Référentiel Général d'Écoconception des Services Numériques) est un cadre officiel pour concevoir des services numériques responsables. S'y engager, c'est accepter d'optimiser les ressources et de limiter l'empreinte environnementale de ce qu'on construit.
Le bon réflexe
Quand vous voyez une certification sur un site, posez-vous la question : est-ce que ce label engage l'entreprise sur des standards vérifiables ? Est-ce qu'il a un impact concret sur mon projet ou mon budget ? Si la réponse est non des deux côtés, c'est du décor.
La communication quand ça ne se passe pas comme prévu ⚠️
Vous pouvez choisir la meilleure entreprise de développement informatique du marché, avec les meilleures certifications et la meilleure méthode de travail. Il y aura des imprévus. C'est la réalité de ce type de projet.
Un projet de développement sur-mesure, c'est de la construction. Il y a des zones d'incertitude, des contraintes qu'on découvre en route, des ajustements à faire. Ce n'est pas un problème. Le problème, c'est quand le prestataire essaie de cacher les difficultés au lieu de les remonter.
Ce qui fait la différence
Un bon prestataire ne vous dit pas que tout va bien quand ce n'est pas le cas. Il vous appelle pour dire : "On a un obstacle sur tel point. Voici ce que ça implique en délai et en coût. Voici les options." C'est inconfortable sur le moment. C'est aussi infiniment préférable à la découverte d'un problème qui a grossi pendant des semaines sans que personne ne vous en parle.
Si la réponse à "racontez-moi un projet qui a mal tourné" est "ça ne nous arrive jamais", fuyez.
La question à poser
Demandez au prestataire de vous raconter un projet qui ne s'est pas déroulé comme prévu. Comment ils ont géré la situation. Ce qu'ils en ont tiré. Ce qu'ils feraient différemment.
Si la réponse est "ça ne nous arrive jamais" ou "tous nos projets se passent bien"... soyez prudent. Soit l'entreprise manque d'expérience, soit elle n'est pas honnête. Dans les deux cas, ce n'est pas rassurant pour la suite.
Choisir au-delà du devis 💡
Choisir une entreprise de développement informatique, c'est choisir un partenaire pour des mois, parfois des années. Le montant du devis compte, mais il ne dit rien sur la qualité de la relation, la rigueur du suivi, la pérennité de ce qui sera construit, ou la capacité de l'équipe à gérer les coups durs.
Les cinq critères que nous venons de détailler ne figurent dans aucun devis. Ils ne se vérifient pas non plus en lisant une plaquette commerciale. Ils se vérifient dans les échanges, dans les questions que vous posez et les réponses que vous obtenez.
Un prestataire qui comprend votre métier, qui vous montre le projet régulièrement, qui vous garantit la propriété et la portabilité de votre code, qui s'engage sur des standards vérifiables et qui communique franchement quand les choses se compliquent — c'est un prestataire avec qui vous pouvez construire quelque chose de solide.
Prenez le temps de vérifier ces points avant de signer. Votre projet le mérite.
Récapitulatif : les questions à poser avant de signer 📋
| Question à poser | Ce que vous cherchez à vérifier |
|---|---|
| "Pouvez-vous me raconter un projet récent dans mon secteur ?" | Compréhension métier : le prestataire s'intéresse-t-il à votre activité ou se contente-t-il d'exécuter ? |
| "À quelle fréquence vais-je voir le produit en cours ?" | Suivi projet : allez-vous avoir de la visibilité régulière ou subir un effet tunnel ? |
| "Le code me appartient-il ? Ai-je accès au code source ?" | Propriété et portabilité : pourrez-vous changer de prestataire si nécessaire ? |
| "Quelles certifications avez-vous, et qu'est-ce qu'elles impliquent concrètement ?" | Engagements vérifiables : labels réels ou simple décoration ? |
| "Racontez-moi un projet qui ne s'est pas passé comme prévu." | Transparence : l'équipe gère-t-elle les difficultés ou les cache-t-elle ? |
