« Le développement avance bien, on vous montre ça bientôt. » Si cette phrase revient depuis six semaines sans que vous ayez rien vu tourner, vous avez un problème. Je le dis en tant que prestataire : les projets qui déraillent ne meurent presque jamais d'un problème technique. Ils meurent d'un pilotage absent — un client non technique qui n'ose pas poser de questions, un prestataire qui en profite (par malhonnêteté parfois, par dérive naturelle le plus souvent), et six mois plus tard un budget consommé pour un produit invisible.
La bonne nouvelle : piloter un prestataire tech ne demande aucune compétence en programmation. Ça demande des rituels, des questions précises et le courage d'exiger des preuves. Voici la méthode que je recommande — et que j'applique moi-même côté prestataire, parce qu'un client bien outillé fait de meilleurs projets.
La règle d'or : exigez du visible et du vérifiable chaque semaine. Une démo du logiciel qui fonctionne, un accès permanent au code source et à un environnement de test : si votre prestataire refuse l'un de ces trois points, changez de prestataire.
Avant de signer : verrouiller trois points non négociables
1. La propriété du code et des accès
Le contrat doit stipuler que le code, les maquettes et les données vous appartiennent (juridiquement : une cession des droits de propriété intellectuelle, au fil de l'eau ou au paiement). Concrètement, dès la première semaine : le code est hébergé sur un compte GitHub (ou équivalent) dont vous êtes propriétaire, et tous les comptes critiques — nom de domaine, hébergement, stores, services tiers — sont ouverts à votre nom. Un prestataire honnête n'y voit aucun inconvénient. Un prestataire qui résiste prépare, consciemment ou non, votre dépendance.
2. Un périmètre écrit, découpé en jalons
Pas « développement de l'application : 40 000 € », mais des lots livrables et testables : authentification, tableau de bord, paiement… chacun avec son montant et son critère d'acceptation. C'est tout l'objet du cadrage de projet, la meilleure assurance-vie de votre budget.
3. Un échéancier de paiement aligné sur les livraisons
Un acompte de 20 à 30 % est normal. Payer 80 % avant d'avoir rien vu ne l'est pas. Chaque paiement suit une livraison démontrée, pas une date du calendrier.
Les rituels de suivi qui changent tout
- La démo hebdomadaire, sur le vrai produit. Trente minutes, chaque semaine, où le prestataire montre le logiciel en fonctionnement — pas des slides, pas des maquettes, pas « le code avance ». Ce rituel unique élimine 80 % des dérives, parce qu'il rend le retard visible en sept jours au lieu de trois mois.
- Un environnement de test permanent. Une URL où vous pouvez manipuler la dernière version quand vous voulez, sans demander la permission. C'est standard chez tout professionnel sérieux.
- Un point d'avancement écrit : fait / en cours / bloqué, avec les décisions attendues de votre côté. Dix lignes suffisent, mais elles créent une trace opposable.
- Un canal de communication unique (et pas six fils WhatsApp) : les décisions s'y écrivent, les malentendus s'y dissipent.
Les questions à poser (sans être technique)
Vous n'avez pas besoin de comprendre les réponses en détail : la manière dont on vous répond est déjà une information. Quelques questions qui font mouche :
- « Montrez-moi cette fonctionnalité en marche sur mon environnement de test. » — La seule preuve qui compte.
- « Si vous disparaissez demain, qu'est-ce qu'il me manque pour continuer avec quelqu'un d'autre ? » — La réponse doit être « rien : vous avez le code, les accès et la documentation ».
- « Qu'est-ce qui vous inquiète le plus dans le projet en ce moment ? » — Un prestataire qui répond « rien » à chaque fois ne vous dit pas la vérité ; tout projet a des risques.
- « Cette demande, combien coûte-t-elle et que décale-t-elle ? » — À poser à chacune de vos propres demandes. Le dérapage budgétaire vient autant des clients que des prestataires.
- « Où en est-on sur le budget consommé par rapport à l'avancement ? » — 60 % du budget pour 30 % du périmètre doit déclencher une conversation immédiate.
Les red flags, du plus bénin au plus grave
| Signal | Gravité | Réaction |
|---|---|---|
| Jargon systématique, réponses évasives à vos questions | Modérée | Exigez des reformulations simples : qui maîtrise sait vulgariser |
| Démos repoussées deux semaines de suite | Sérieuse | Rendez-vous de recadrage, plan de rattrapage écrit |
| « C'est fini à 90 % » pendant des semaines | Sérieuse | Passez en revue le reste ligne par ligne, avec dates |
| Refus de vous donner accès au code source | Critique | Mise en demeure ; préparez la sortie |
| Demande de paiement anticipé pour « débloquer » le projet | Critique | Ne payez pas sans livraison ; conseil juridique |
Challenger un devis sans expertise technique
Un devis se challenge sur sa structure plus que sur ses prix. Méfiez-vous d'un forfait global sans détail : demandez le découpage par lot, les hypothèses prises, ce qui est inclus (tests, corrections, mise en production, garantie) et ce qui ne l'est pas. Comparez deux ou trois devis en sachant qu'un écart de 1 à 3 est normal sur le marché — les extrêmes s'expliquent souvent par un périmètre compris différemment, rarement par du génie ou de l'arnaque. J'ai détaillé la mécanique dans comprendre et comparer les devis tech. Et si vous hésitez encore entre types de prestataires, mon comparatif freelance vs agence pose les critères objectifs.
Les erreurs côté client (oui, il y en a)
- Changer d'avis chaque semaine sans accepter l'impact budget/délai. Chaque demande passe par un mini-avenant, même informel : coût, délai, arbitrage.
- Disparaître pendant trois semaines puis s'étonner que le projet ait avancé dans la mauvaise direction. Votre disponibilité pour valider fait partie du projet.
- Négocier le prix en gardant le même périmètre. Ce que vous obtiendrez, c'est du travail bâclé et de la dette technique invisible. Négociez le périmètre, pas la qualité.
- Attendre la fin pour tester. Testez chaque lot dès sa livraison, avec de vrais cas métier : un retour à chaud coûte dix fois moins cher qu'un retour trois mois après.
Comprendre le vocabulaire minimal, sans devenir technique
Vous n'avez pas besoin de savoir coder, mais quelques mots reviennent systématiquement dans les échanges : apprenez-les, ils vous éviteront bien des malentendus.
- Sprint : une période de travail fixe (souvent deux semaines) à l'issue de laquelle une démo doit être possible. Si les « sprints » durent en réalité six semaines sans livrable, le mot est vidé de son sens.
- Environnement de recette (ou de test) : une version du logiciel où vous pouvez essayer les nouveautés avant qu'elles ne passent en production, c'est-à-dire chez vos vrais utilisateurs. Son absence est un red flag en soi.
- Ticket ou user story : une tâche unitaire, décrite du point de vue de l'utilisateur (« en tant que client, je veux… »). Demandez à voir la liste des tickets en cours : leur nombre et leur état vous renseignent plus qu'un long discours.
- Régression : une fonctionnalité qui marchait et qui casse suite à une autre modification. Des régressions fréquentes signalent une absence de tests automatisés — un sujet à creuser avec votre prestataire, sans forcément en comprendre le détail technique.
Ce lexique tient sur une page : gardez-le sous la main, il suffit à suivre 90 % des réunions de suivi sans vous sentir perdue.
Bien gérer la fin de mission ou le changement de prestataire
Un projet ne se termine pas toujours en douceur, et c'est précisément dans ces moments — fin de contrat, désaccord, ou simple envie de changer d'interlocuteur — que la préparation faite en amont paie. Quelques réflexes à adopter :
- Demandez une passation écrite avant le dernier paiement, pas après. Un document qui liste les accès, les choix techniques, les points de vigilance et les contacts (hébergeur, nom de domaine, services tiers) vous évite des semaines de recherche à l'aveugle le jour où vous en avez besoin.
- Vérifiez que tout tourne sans votre prestataire actuel :déconnectez-le temporairement d'un accès secondaire et confirmez que le site ou l'application continue de fonctionner. Un système qui dépend d'une personne précise pour rester en ligne est un risque, pas un service.
- Faites auditer avant de faire reprendre. Un nouveau prestataire qui reprend un projet a besoin de comprendre l'existant avant d'agir ; c'est l'objet de l'audit de reprise de projet, qui évite de payer deux fois pour redécouvrir ce que vous saviez déjà.
Un bon prestataire n'a rien à cacher, et un bon client vérifie quand même. Les projets réussis que je vois passer ont tous ce point commun : la confiance s'y construit sur des preuves hebdomadaires, pas sur des promesses.
Besoin d'un second regard sur votre projet ?
Je réalise régulièrement des missions de conseil ponctuelles pour des fondateurs non techniques : relecture de devis, audit d'avancement, mise en place des rituels de suivi — y compris quand le développement est assuré par un autre prestataire. Réservez un appel découverte : 30 minutes suffisent souvent à y voir clair.
À lire ensuite : Bien cadrer un projet tech et Estimer et comparer les devis.