Comment externaliser le développement d’une app sans se faire avoir

Le manuel opérationnel du fondateur non technique pour mener un développement externalisé de façon que l’app soit livrée, fonctionne et vous appartienne à la fin.

Une fondatrice que nous connaissons a payé 55 000 euros à une agence bien notée pour construire une app de marketplace. Neuf mois plus tard, elle avait une démo qui marchait sur le téléphone du patron de l’agence et nulle part ailleurs, un code que personne en dehors de cette maison ne pouvait ouvrir, et une facture pour « périmètre supplémentaire ». Quand elle a demandé le code source, le contrat disait que l’agence en restait propriétaire jusqu’au paiement final, et le paiement final dépendait d’un lancement qui ne cessait de glisser. Elle avait externalisé le développement et, sans le vouloir, externalisé le contrôle du seul produit de son entreprise.

Voilà le vrai risque, et ce n’est pas celui dont les résultats de recherche vous préviennent.

Externaliser le développement d’une app, c’est confier à une équipe extérieure la conception et la construction de votre logiciel au lieu d’employer vous-même des ingénieurs. Bien fait, c’est la voie la plus rapide pour qu’un fondateur non technique mette un vrai produit sur le marché sans devenir gestionnaire de technologie. Mal fait, cela produit exactement le naufrage ci-dessus. La différence ne tient presque jamais à la qualité des développeurs. Elle tient à savoir si vous avez gardé le rapport de force aux cinq points où les fondateurs le cèdent sans s’en apercevoir. Voici le manuel pour le garder.

Si vous hésitez encore à externaliser, commencez par notre analyse sur monter une équipe interne plutôt qu’externaliser. Cet article suppose que vous avez déjà tranché et qu’il faut maintenant le piloter.

D’abord, sachez ce que vous achetez vraiment

« Externalisation » est un seul mot pour quatre arrangements très différents, et les histoires d’échec commencent souvent par un fondateur qui achète le mauvais.

Le premier est le freelance : une personne, à l’heure ou au forfait, peu cher, rapide, et un point de défaillance unique. Le deuxième est le staff augmentation, où vous louez un ou plusieurs développeurs qui travaillent sous votre direction mais restent sur la paie d’une autre entreprise. Nous avons écrit un texte entier sur le fonctionnement réel du staff augmentation ; en résumé, il vous donne les mains mais attend que vous fournissiez la tête. Le troisième est le projet à périmètre fixe, où un studio chiffre un prix pour livrer une chose définie. Le quatrième est l’équipe dédiée, un escadron continu qui fonctionne comme votre département d’ingénierie sans être votre salarié.

Pour une première app avec un fondateur non technique, le projet à périmètre fixe et l’équipe dédiée sont en général les bons formats. Les freelances cassent dès qu’une personne disparaît, et le staff augmentation ne marche que si quelqu’un de votre côté sait réellement diriger des ingénieurs. Choisissez l’arrangement qui correspond au jugement technique que vous pouvez apporter, pas celui dont l’étiquette est la moins chère. L’endroit où cette équipe se trouve géographiquement, dans votre pays, à proximité ou à l’autre bout du monde, est une décision distincte, avec ses propres arbitrages.

Phase 1 : verrouillez le périmètre avant de demander des devis

La plus grande erreur des fondateurs est d’appeler les agences d’abord et d’écrire le périmètre ensuite. Vous finissez par laisser ceux qui vont soumissionner définir le travail. Évidemment que le périmètre gonfle.

Avant de parler à qui que ce soit, écrivez trois choses en langage clair. Ce que l’app doit faire pour son premier vrai utilisateur. Ce qu’elle ne fera explicitement pas dans la version un. Et comment vous saurez que ça a marché. Vous n’avez pas besoin d’une spécification technique. Vous avez besoin d’une description assez claire pour que deux prestataires différents chiffrent à peu près la même chose. Quand les devis reviennent très différents, l’écart mesure l’ambiguïté de votre périmètre, pas la différence de talent entre eux.

Ce document est aussi votre défense contre la phrase la plus chère du logiciel, « périmètre supplémentaire ». Un changement n’est supplémentaire que s’il n’était pas dans la description d’origine. Si la description vit dans votre tête, chaque désaccord se règle en faveur du prestataire. Si elle vit sur papier, vous avez une référence acceptée par les deux parties.

Une étude de McKinsey et Oxford sur les grands projets informatiques a constaté qu’ils dépassent, en moyenne, environ 45 pour cent du budget, et que les dérapages viennent plus d’objectifs flous et d’exigences changeantes que d’un mauvais code. Vous n’allez pas battre ce risque par l’ingénierie. Vous le gérez en décidant ce que vous allez construire avant de payer quelqu’un pour le construire.

Signal d’alerte : le prestataire qui donne un prix et un délai fermes avant de poser une seule question difficile sur vos utilisateurs. Soit il devine, soit il prévoit de facturer l’écart.

Phase 2 : choisissez sans vous faire vendre

Chaque guide « comment externaliser » qui se classe sur cette recherche a été écrit par une entreprise qui veut être la réponse. Lisez-les pour ce qu’ils révèlent, puis évaluez les prestataires sur des choses que leur marketing ne peut pas truquer.

Demandez à parler aux ingénieurs qui travailleraient réellement sur votre build, pas au commercial ni à un responsable d’allure senior qu’on promène dans le pitch et qui disparaît après la signature. Demandez une référence d’un projet qui a échoué ou dérapé, et écoutez comment ils décrivent ce qui s’est mal passé. Une équipe qui raconte un échec avec honnêteté a réglé ses comptes avec son propre travail. Une équipe qui n’a que des cas triomphants est soit nouvelle, soit en train de monter le récit.

Demandez comment ils font le handoff du code, par écrit, avant de signer. Où vit le dépôt ? Qui possède les comptes ? Qu’arrive-t-il à votre projet si vous cessez de travailler avec eux le mois prochain ? Un bon partenaire répond aussitôt parce qu’on lui a déjà posé la question. Le mauvais partenaire prend la question pour de la méfiance, ce qui vous dit tout.

Signal d’alerte : le prix nettement en dessous des autres. Le développement d’app a un plancher réel d’heures qualifiées. Un devis très en dessous du groupe est un devis pour une chose différente, plus petite ou plus fragile que ce que vous croyez acheter, et l’écart réapparaît en « périmètre supplémentaire » plus tard.

Phase 3 : structurez l’accord pour que le rapport de force reste chez vous

C’est la phase qui a sauvé ou coulé chaque fondateur de notre histoire d’ouverture, et elle tient à trois clauses que la plupart des gens survolent.

Propriété intellectuelle. Le contrat doit dire que vous possédez tout le travail produit, code source compris, dès sa création, pas au paiement final. Le code commandé n’est pas automatiquement le vôtre : dans la plupart des juridictions, sans cession écrite, ceux qui ont écrit le code en conservent des droits (le droit d’auteur américain est explicite là-dessus). C’est une correction d’un paragraphe et la phrase la plus importante de l’accord. Nous détaillons le document entier dans notre guide sur le contrat de développement logiciel.

Paiement lié à des jalons qui fonctionnent, pas au calendrier. Payez pour un progrès démontrable et déployé : un écran de connexion qui connecte vraiment, un paiement qui débite vraiment. Ne payez jamais un gros solde à la fin, et ne laissez jamais le paiement précéder la livraison de plus d’un jalon. L’argent est votre seul rapport de force. Dépensez-le en dernier.

Accès dès le premier jour. Vous devez posséder le dépôt, les comptes cloud, le domaine et les fiches sur les stores dès le premier commit, le prestataire travaillant à l’intérieur de vos comptes. Si ces actifs sont au nom du prestataire, vous n’avez pas un produit. Vous avez un otage.

Signal d’alerte : toute version de « on vous transfère tout à la fin ». Tout doit être à vous dès le début. Le handoff devrait être un non-événement parce que rien n’a jamais quitté votre garde.

Phase 4 : pilotez le build même sans savoir lire le code

Les fondateurs croient que ne pas être technique veut dire ne pas pouvoir gérer le travail. C’est l’inverse. Les choses qui coulent les builds externalisés sont visibles par quiconque y prête attention, et aucune n’exige de lire une ligne de code.

Exigez un logiciel qui fonctionne toutes les une à deux semaines, tournant sur un vrai appareil, pas un diaporama de progrès. Un logiciel qui existe se clique. Un logiciel décrit dans un point d’avancement peut être n’importe quoi. Si trois semaines passent sans rien que vous puissiez ouvrir et toucher, c’est l’avertissement, aussi bon que le compte rendu paraisse.

Gardez une personne nommée de leur côté responsable de la livraison, et un décideur du vôtre qui répond en moins d’une journée. La plupart des builds externalisés n’échouent pas à cause d’une mauvaise ingénierie. Ils calent parce qu’une question est restée une semaine dans la boîte du fondateur et que l’équipe a construit autour du silence. La réponse lente est un coût caché que vous payez en périmètre.

Surveillez une dérive précise : le build qui ajoute sans cesse des fonctionnalités qu’aucun utilisateur n’a demandées. C’est le feature creep, et une équipe externalisée y a un intérêt silencieux, car plus de fonctionnalités veut dire plus d’heures facturables. Votre document de périmètre est le remède. Tout ce qui n’y figure pas est une conversation, pas un réglage par défaut.

Phase 5 : devenez propriétaire de l’actif au handoff

La relation se termine de l’une de deux façons. Soit elle a été montée pour que le handoff ne soit rien, soit vous découvrez au pire moment que vous ne pouvez pas vous passer des gens qui partent.

Avant le paiement final, confirmez que vous pouvez confier le projet à une autre équipe et qu’elle peut le faire tourner. Cela veut dire que le code est dans votre dépôt, que les comptes sont à votre nom, qu’il existe un document écrit sur comment déployer et faire tourner la chose, et que quelqu’un d’autre que l’auteur d’origine l’a ouvert et compris. Si une seule personne au monde peut garder votre app en vie, vous n’avez pas fini d’externaliser. Vous avez juste changé de qui vous dépendez.

Un handoff propre est aussi le test honnête de la qualité du travail. Un logiciel fait pour être transmis est fait avec clarté, parce que l’équipe savait que quelqu’un d’autre le lirait. Un logiciel fait pour vous garder captif est fait pour vous garder captif. Vous sentirez la différence la première fois que vous tenterez de partir.

Combien ça coûte, honnêtement

Les fondateurs cherchent un chiffre et il n’y en a pas. Une app simple d’une équipe compétente tombe en général dans les dizaines de milliers d’euros ; un produit complexe, multi-faces, avec paiements et fonctions en temps réel, atteint les six chiffres. Les fourchettes honnêtes, et ce qui les fait bouger, sont dans notre analyse sur combien coûte le développement d’une app.

Le cadrage le plus utile : pas cher et brûlé coûte plus cher que juste et fini. Le marketplace à 55 000 euros qui n’a rien produit a coûté bien plus qu’un build à 85 000 euros qui est sorti, parce que le premier a aussi coûté neuf mois, la fenêtre de levée que ces mois contenaient, et la reconstruction. Mettez un prix sur le résultat entier, pas sur la facture.

Le vrai test

Retirez les phases et une question tranche : à chaque étape, qui détient le rapport de force ? Si la réponse est toujours « nous, par conception », parce que vous avez verrouillé le périmètre d’abord, payé contre preuve, possédé les actifs dès le premier jour et construit vers une sortie propre, alors externaliser le développement de l’app est le coup le plus intelligent qu’un fondateur non technique puisse jouer. Si le rapport de force glisse vers le prestataire, aucun talent de son côté ne vous sauve, parce que ses intérêts et les vôtres se sont séparés en silence.

Vous n’avez pas besoin d’apprendre à coder. Vous avez besoin de refuser de céder le contrôle de la seule chose sur laquelle votre entreprise tourne. C’est une décision, et elle est entièrement la vôtre.

Foire aux questions

Combien coûte l’externalisation du développement d’une app ?

Une app simple d’une équipe qualifiée tombe en général dans les dizaines de milliers d’euros. Un produit complexe, avec paiements, plusieurs types d’utilisateurs ou fonctions en temps réel, peut atteindre six chiffres. La variable, c’est le périmètre, pas le taux horaire, et c’est pourquoi un document de périmètre serré est le contrôle de coût le moins cher dont vous disposez. Voyez notre analyse de coûts complète pour les fourchettes et ce qui les fait bouger.

Combien coûte le fait de payer quelqu’un pour développer une app ?

Les mêmes forces s’appliquent, que ce « quelqu’un » soit un freelance, un studio ou une équipe dédiée. Un freelance seul chiffre le nombre le plus bas et porte le plus grand risque de point de défaillance unique. Un studio ou une équipe dédiée coûte plus et absorbe ce risque. Comparez le résultat et la propriété au total, pas le prix affiché.

Quels sont les quatre types d’externalisation ?

Pour le développement d’app, les quatre pratiques sont : le freelance (une personne, le moins cher, le plus risqué), le staff augmentation (des développeurs loués que vous dirigez), le projet à périmètre fixe (un studio livre une chose définie pour un prix convenu) et l’équipe dédiée (un escadron continu qui fonctionne comme votre département d’ingénierie). La plupart des premiers builds entrent dans le projet à périmètre fixe ou l’équipe dédiée.

Est-il sûr d’externaliser le développement d’une app ?

Oui, quand le contrat vous donne le code source et les comptes dès le premier jour, que le paiement suit des jalons qui fonctionnent, et que le build est monté pour un handoff propre. Le danger n’est jamais le lieu ou l’équipe seuls. C’est un accord structuré pour que le rapport de force reste chez le prestataire. Structurez-le pour qu’il reste chez vous.

Externaliser le développement d’app, est-ce légal ?

Oui. Confier à une équipe extérieure, locale ou internationale, la construction de votre logiciel est standard et légal. Le seul point juridique qui vous importe est la propriété intellectuelle : obtenez une cession écrite de tout le travail produit pour que le code soit, sans ambiguïté, le vôtre.