Station Eight Labs

2026-06-01

Comment choisir une entreprise de développement logiciel

Au-delà du portfolio et du pitch — les questions qui prédisent vraiment si un partenaire tiendra.

Neeraj Singh

Les portfolios montrent la meilleure journée qu’une entreprise ait jamais eue. Ils ne disent presque rien sur la semaine moyenne — comment une équipe communique quand un sprint dérape, comment elle gère une exigence qui change après la signature de l’estimation, si elle osera vous dire qu’une fonctionnalité est une mauvaise idée. Ce sont ces questions qui valent la peine d’être posées avant de regarder une nouvelle étude de cas.

Demandez qui possède réellement le code, le dépôt et les comptes cloud une fois la mission terminée. Une entreprise qui garde les clés n’est pas un partenaire ; c’est un bailleur. La propriété doit être explicite dans le contrat, pas une note de bas de page que vous découvrez en essayant de changer de prestataire.

Demandez comment elle cadre le travail. Une proposition vague qui saute directement à un prix fixe sans phase de découverte sous-évalue le risque, ou le surévalue largement — ni l’un ni l’autre n’est bon pour vous. Une courte phase de découverte payante, qui produit un vrai document de cadrage, est le signe que l’estimation qui suit est honnête.

Demandez ce qui se passe après le lancement. Un logiciel n’est pas terminé au déploiement ; il se dégrade en silence — les dépendances vieillissent, les usages changent, une bibliothèque reçoit une alerte de sécurité. Une entreprise sans réponse sur la maintenance prévoit de vous livrer un système et de disparaître. Un contrat de suivi ou un accord de support clair fait la différence entre un lancement et un produit.

Enfin, faites confiance à la conversation elle-même. Une équipe qui s’oppose à une mauvaise idée, s’intéresse à votre vraie contrainte plutôt qu’à sa technologie préférée, et vous donne une réponse franche sur les risques de délai, tiendra plus probablement sous pression qu’une équipe qui approuve tout pendant l’appel commercial.

Les appels de référence valent plus que les portfolios, mais seulement si vous posez la bonne question. Plutôt que « étiez-vous satisfait », demandez « qu'est-ce qui s'est mal passé pendant le projet, et comment l'ont-ils géré ». Toute mission réelle traverse un moment difficile ; une référence incapable d'en citer un est soit polie, soit n'a pas travaillé assez longtemps avec l'équipe pour en rencontrer un.

Observez comment un partenaire potentiel réagit à un premier brief vague. Une équipe qui chiffre immédiatement un prix vous dit qu'elle n'a pas besoin de comprendre le problème pour le chiffrer — ce qui signifie que le prix ne concerne pas vraiment votre problème. Une équipe qui pose une dizaine de questions de clarification avant de parler de coût fait déjà le travail avant même la signature.

La taille n'est un gage de qualité dans aucun sens. Un studio de cinq personnes peut tenir un système pendant des années ; une structure de cent personnes peut faire tourner trois équipes différentes sur votre compte avant la livraison. Demandez précisément qui fera le travail au quotidien, pas seulement qui est présent lors du rendez-vous commercial.

Questions à poser, et ce que la réponse révèle

QuestionBonne réponseSignal d'alarme
Qui possède le code et les comptes après le lancement ?« Vous, dès le premier jour. »Vague, ou « nous gérons ça pour vous ».
Comment cadrez-vous le travail ?Une courte phase de découverte payante d'abordUn prix fixe sans appel de cadrage
Que se passe-t-il après le lancement ?Un contrat de suivi ou de support clairPas de réponse, ou « on verra ».

À retenir

  • Demandez qui possède le code et les comptes cloud une fois la mission terminée — la réponse doit être explicite, pas une note de bas de page.
  • Une proposition vague qui saute la découverte pour un prix fixe sous-évalue ou surévalue largement le risque.
  • Demandez ce qui se passe après le lancement ; une équipe sans réponse sur la maintenance prévoit de disparaître après le déploiement.
  • Les appels de référence doivent demander ce qui s'est mal passé, pas si le client était satisfait.
  • Demandez précisément qui fera le travail au quotidien, pas seulement qui est présent au rendez-vous commercial.

Neeraj Singh

Ingénieur full stack, IA et cloud chez Station Eight Labs — plus de six ans à livrer des systèmes dans la fintech, la santé et la mobilité.