Red flags prestataire dev : ne signe pas avant de lire ça

Un fondateur dépense 80 000 EUR en 5 mois. L’agence sous-traitait tout en offshore. Zéro livrable. Les red flags d’un mauvais prestataire de développement étaient là dès le départ. Personne ne les a vus.

Les signaux classiques - devis vague, prix trop bas - tu les connais déjà. Ce guide couvre les autres : les arnaques subtiles, les signaux qui apparaissent pendant le projet, et les questions exactes pour démasquer un mauvais prestataire dev. La méthode complète de sélection est dans un guide dédié.

Les red flags avant de signer

Il dit oui à tout

Un prestataire qui accepte chaque demande sans poser de question n’est pas arrangeant. Il n’a pas compris ton projet. Ou il s’en fiche - il facturera les changements après.

La majorité des projets subissent du scope creep. Le prestataire qui ne challenge pas les specs livre exactement ce que tu as demandé - pas ce dont tu avais besoin. Les meilleurs développeurs disent non. Ils posent des questions, proposent des alternatives, remettent en cause les fonctionnalités inutiles.

La question qui démasque : “Si j’ajoute une fonctionnalité en cours de route, qu’est-ce que ça change sur le planning et le budget ?” Bonne réponse : il challenge l’impact. Mauvaise réponse : “Pas de problème.”

Pas de phase de discovery

Un prestataire qui envoie un devis sans t’avoir posé 20 questions chiffre dans le vide. La discovery - analyse du besoin, définition du scope, validation de la faisabilité technique - c’est ce qui sépare un projet livré d’un gouffre financier.

Des équipes de 16 personnes travaillant 60 heures par semaine pendant 12 semaines pour produire des écrans vides. De belles interfaces sans aucune logique derrière. Personne n’avait validé la faisabilité avant de coder. Ce type de dérive coûte des dizaines de milliers d’euros et des mois de retard.

La question qui démasque : “Quels livrables d’analyse produisez-vous avant le premier sprint de code ?” Bonne réponse : spécifications fonctionnelles, maquettes, architecture technique. Mauvaise réponse : “On commence directement.”

L’équipe de vente n’est pas l’équipe de dev

Le bait-and-switch est le piège le plus insidieux. Des seniors impeccables pilotent l’avant-vente. Présentations soignées, démos convaincantes, réponses techniques solides. Tu signes. Le lendemain, ces seniors sont sur un autre appel d’offre. Les juniors prennent le relais. Les caméras restent éteintes en réunion. La qualité chute.

Le cas extrême : des agences qui ne sont que des façades commerciales. Elles sous-traitent tout en offshore, empochent la marge, et tu ne le découvres que quand le projet déraille. Le recours juridique est quasi impossible quand le prestataire réel est dans un autre pays.

La question qui démasque : “Qui exactement va coder mon projet ? Puis-je le rencontrer avant de signer ?” Bonne réponse : il organise un appel. Mauvaise réponse : “L’équipe sera affectée après la signature.”

Le portfolio n’est pas testable

Des screenshots, tout le monde peut en montrer. Même des maquettes Figma passent pour des applications livrées. Le vrai test : des applications en production que tu peux utiliser toi-même.

La question qui démasque : “Donnez-moi 3 applications livrées que je peux utiliser maintenant.” Bonne réponse : il envoie les liens et les accès démo. Mauvaise réponse : “On ne peut pas partager pour des raisons de confidentialité” - sur 100% de son portfolio.

Pas de clause de sortie

Un prestataire qui utilise des technologies propriétaires ou qui refuse de documenter le code te rend captif. Le jour où la relation se termine, tu n’as aucune alternative.

Le scénario : un produit construit sur un framework propriétaire non documenté. Le prestataire exige un montant délirant pour la maintenance. Le client n’a pas le choix - personne d’autre ne peut intervenir sur le code. Ce type de vendor lock-in transforme un fournisseur en dictateur.

Changer de prestataire en cours de route double le coût du projet. C’est le pattern que je vois se répéter.

La question qui démasque : “Si j’arrête la collaboration dans 3 mois, que se passe-t-il avec le code et la documentation ?” Bonne réponse : clause claire, code sur ton compte, doc livrée. Mauvaise réponse : silence ou flou.

Les 3 classiques (rappel)

Si tu ne retiens que trois choses :

• Le code n’est pas sur ton compte dès le jour 1 ? Deal breaker. C’est le signal numéro 1 et il est non négociable. La propriété du code source est la seule chose qui te protège si tout dérape.
• Le devis ne détaille pas les fonctionnalités ? C’est une carte blanche pour les avenants. Un bon devis d’application mobile liste chaque fonctionnalité avec son estimation.
• Le prix est anormalement bas ? Un développeur freelance compétent facture entre 450 et 650 EUR/jour (Malt, 36 146 profils). Un devis à 2 000 EUR pour une application complète cache de la sous-traitance offshore, un junior, ou un produit qui ne fonctionnera pas.

Le guide comment choisir ton prestataire de développement donne la méthode complète en 5 étapes.

Les red flags pendant le projet

Les signaux pré-signature, la plupart des fondateurs les connaissent. Les signaux pendant le projet, presque personne n’en parle. C’est pourtant là que ça déraille.

Les démos montrent des écrans, pas des fonctionnalités

Un prestataire te présente de belles maquettes. Des interfaces soignées. Des transitions fluides. Tu es rassuré. Sauf que rien ne fonctionne derrière.

Le piège est universel. Des milliers d’heures facturées pour des templates d’interface sans logique métier. Le code derrière les écrans n’existe tout simplement pas. Ça ressemble à un produit. Ce n’en est pas un.

La question à poser à chaque démo : “Je clique sur [fonctionnalité], qu’est-ce qui se passe en base de données ?” Si la réponse est floue, le code n’est pas écrit.

Le projet démarre vite puis ralentit

Les premières semaines sont impressionnantes. Les livrables tombent. Les progrès sont visibles. Puis tout ralentit. Chaque sprint livre moins. Les justifications s’allongent. Le planning recule.

C’est le pattern le plus dangereux parce qu’il arrive après les premiers paiements. Le bon progrès initial crée une fausse confiance. Quand le ralentissement devient visible, le budget est déjà entamé.

Le signal : compare la vélocité des 3 premiers sprints avec les 3 suivants. Si elle baisse de plus de 30% sans changement de scope, il y a un problème d’architecture ou de compétence.

Chaque bug corrigé en crée un nouveau

Corriger un bug devrait réduire le nombre total de bugs. Si chaque correction en génère d’autres, c’est le signe d’une dette technique massive ou d’une absence de tests automatisés.

Le cas extrême existe : des équipes offshore qui fabriquent de faux résultats de tests pendant des mois. Un système d’intégration continue configuré pour afficher des succès fictifs. Tout passe au vert. Rien ne fonctionne. Ce type de fraude peut durer plus d’un an sans être détecté.

L’action : demande un audit de code indépendant immédiatement. 2 heures à 200-400 EUR. Si l’audit révèle l’absence de tests ou du code immaintenable, tu as ta réponse.

Le prestataire devient injoignable

Annulations de réunions répétées. Réponses qui arrivent 3 jours plus tard. Messages lus sans suite. Ce n’est pas un oubli ponctuel. C’est le signe que ton projet n’est plus une priorité - ou que le prestataire jongle entre trop de projets simultanément.

La règle : 1 annulation = normal. 3 en un mois = red flag. Au-delà = mets en demeure par écrit et prépare un plan B.

Les 7 questions qui démasquent un mauvais prestataire

Ces questions fonctionnent parce qu’un mauvais prestataire ne peut pas y répondre correctement. Un bon prestataire les trouvera légitimes.

Si le prestataire botte en touche sur 3 questions ou plus, passe au suivant. Ce n’est pas de la méfiance. C’est de la due diligence.

Ce que ça coûte d’ignorer les signaux

Le PMI estime que 109 millions de dollars sont gaspillés par milliard dépensé en projets IT. Entre 25 et 50% des projets externalisés échouent selon le Standish Group. Et une part significative des fonctionnalités développées n’est jamais utilisée par les utilisateurs finaux - le résultat direct d’un prestataire qui dit oui à tout sans challenger le scope.

En pratique, ça donne quoi ?

Le middleman : un fondateur paie 80 000 EUR sur 5 mois à une agence qui se présente comme locale. L’agence sous-traite tout en offshore et empoche la marge. Zéro livrable à la fin. Le fondateur n’a plus de budget pour recommencer.

Le code fantôme : une équipe facture 3 mois de développement. Le code ne compile même pas. L’environnement de développement n’a jamais été installé sur les machines des développeurs. Des rapports de progression hebdomadaires ont été envoyés pendant 12 semaines. Rien ne fonctionnait.

Le chantage maintenance : un prestataire livre une application sur un framework propriétaire. Aucune documentation. Quand le client veut changer de prestataire, le montant demandé pour la transition est prohibitif. Le client est piégé.

Ces cas ne sont pas des exceptions. Ce sont des patterns récurrents que je vois chez les fondateurs qui viennent me voir après un premier projet raté.

La meilleure protection : vérifier les red flags avant de signer, faire signer un NDA à ton développeur et poser les bonnes questions. Si tu veux un cahier des charges solide pour cadrer ton projet, commence par là. Et si tu compares agence vs freelance, les TJM réels et les témoignages t’aideront à trancher.

Si tu veux que je t’aide à construire ton MVP, c’est exactement ce que fait mon agence vibe coding à Paris.

Foire aux questions

C’est quoi un red flag chez un prestataire de développement ?

Un signal d’alerte qui indique un risque élevé de projet raté. Les plus critiques : le prestataire refuse l’accès au code source, il ne te met jamais en contact avec un développeur technique, ou il dit oui à toutes tes demandes sans jamais challenger le scope.

Comment vérifier la fiabilité d’une agence de développement ?

Demande 3 applications en production que tu peux tester toi-même, pas des screenshots. Appelle les anciens clients. Vérifie qui va coder ton projet et exige de le rencontrer. Si l’agence ne peut répondre à aucune de ces demandes, passe à la suivante.

Quels sont les signes d’un mauvais développeur freelance ?

Il accepte tout sans poser de questions. Il refuse de commencer par un test payé d’une semaine. Son portfolio montre des maquettes mais pas d’applications en production. Il ne propose pas de mettre le code sur ton dépôt dès le départ. Les notes et évaluations en ligne ne protègent pas - un freelance peut avoir 4.9 étoiles et produire du code immaintenable.

Comment éviter les arnaques dans le développement d’application ?

Trois règles : le code source est sur ton compte GitHub dès le jour 1, le paiement se fait par jalons liés à des livrables fonctionnels, et tu exiges un interlocuteur technique direct. Si un prestataire refuse ces trois conditions, il a quelque chose à cacher.

Faut-il faire un audit de code indépendant ?

Oui, surtout si tu n’es pas technique. Deux heures d’audit par un développeur indépendant coûtent 200 à 400 EUR et peuvent révéler du code immaintenable, des failles de sécurité ou une architecture qui ne tiendra pas la montée en charge. C’est l’investissement le plus rentable que tu puisses faire sur un projet externalisé.

Peut-on changer de prestataire en cours de projet ?

Oui, à condition de posséder le code source, la documentation et les accès aux services. Si tout est sur ton compte dès le début, n’importe quel développeur compétent peut reprendre le projet. Si le prestataire contrôle tout, tu repars de zéro et le coût double.

Le prix bas est-il toujours un red flag ?

Un prix anormalement bas cache presque toujours de l’offshore non déclaré, un développeur junior, ou un scope sous-estimé volontairement pour signer. Un développeur freelance compétent en France facture entre 450 et 650 EUR par jour (Malt). En dessous, pose des questions sérieuses.

Comment protéger son code source avec un prestataire externe ?

Le dépôt de code est sur ton compte GitHub ou GitLab dès le premier commit. Pas à la livraison, pas quand le projet est fini. Ajoute une clause de propriété intellectuelle explicite dans le contrat. Si le prestataire refuse, c’est le red flag numéro 1.

Quelles clauses contractuelles protègent contre les mauvais prestataires ?

Clause de propriété du code dès le jour 1, jalons de paiement liés à des livrables fonctionnels, clause de sortie avec délai et conditions, obligation de documentation technique, et interdiction de sous-traitance non déclarée. Un bon contrat protège les deux parties.

Comment détecter la sous-traitance offshore cachée ?

Demande qui va coder et exige de le rencontrer en visio. Vérifie les fuseaux horaires des commits sur le dépôt. Si les réunions techniques sont systématiquement évitées ou si les réponses arrivent décalées de 6 à 8 heures, il y a un intermédiaire. L’article agence vs freelance détaille les patterns à surveiller.