À la fin de mon article sur les coûts, il y a une promesse : celle d'écrire un texte à part, sans fard, sur les expériences et les risques. Le voici. Cherchez « faire développer une application en Inde » et vous tombez sur deux sortes de textes. Des pages de prestataires où tout a l'air fluide. Et des forums où quelqu'un a perdu son argent. Les deux disent vrai. Ni l'un ni l'autre n'écrit ce qui se passe réellement quand une collaboration de ce type se défait.
J'ai fondé CODT en 2017 et je la dirige depuis Gurugram. Depuis, nous avons construit pour des entreprises dans plus de dix pays. Certaines des raisons pour lesquelles ces projets échouent tiennent bel et bien au pays. Ce sont rarement celles dont parle votre comité de direction.
Faire développer une application en Inde : la réponse courte
Cela fonctionne si trois points sont réglés par contrat avant la première ligne de code : où tourne votre système, par quel chemin des développeurs extérieurs y accèdent, et ce qui vous est transféré à la fin. Ces trois points écrits, l'Inde n'est plus qu'une question de lieu. Sans eux, aucun prix ne vous sauvera.
Ce que personne ne met dans l'offre
C'est du décalage horaire qu'on parle le plus, et c'est lui qui fait le moins mal. Gurugram a trois heures et demie d'avance sur Zurich en été, quatre heures et demie en hiver. Notre après-midi est votre matinée. Ce n'est pratiquement jamais là-dessus qu'un projet échoue.
Ce qui le fait échouer est plus banal. Un prestataire annonce un prix ferme dès le premier appel. Cela ressemble à de la fermeté, et c'est l'inverse. Celui qui vous donne un chiffre ferme en trente minutes devrait pouvoir montrer sur quoi il le fonde : quel périmètre, quelles hypothèses, quelle marge. Sans cela, le chiffre est soit trop haut et vous payez pour un risque qui ne se réalisera pas, soit trop bas, et la liste des avenants arrive.
Le deuxième classique, c'est la composition de l'équipe. Des profils seniors dans l'offre, d'autres personnes dans le projet. Une seule question inconfortable avant signature suffit : qui travaillera exactement sur mon projet, nommément, et puis-je parler à cette personne avant de signer ? Si la réponse est évasive, vous avez votre réponse.
Et puis la communication, sujet sur lequel je préfère ne pas être diplomate, parce qu'il concerne mon côté de la table. La politesse peut ressembler à un accord. « Oui » peut vouloir dire « j'ai compris ce que vous voulez », et non « cela me paraît faisable ». J'insiste donc pour que les engagements finissent dans le ticket au lieu de rester dans l'appel. Un malentendu qui n'apparaît qu'en revue coûte plus cher qu'une question gênante un mardi.
Les trois questions qui décident de tout
Ces trois-là vous mèneront plus loin en vingt minutes que n'importe quelle liste de références. Elles cherchent à savoir si quelqu'un a déjà dû y répondre.
| Question | À quoi ressemble une réponse sérieuse |
|---|---|
| Où tourne mon système ? | Dans votre propre juridiction. Fixé pendant le cadrage, comme élément d'architecture. |
| Comment les développeurs y accèdent-ils ? | Par une voie que vous contrôlez : soit un bureau virtuel administré par votre équipe, soit une unique adresse IP fixe de notre bureau, que votre équipe autorise et peut refermer à tout moment. Laquelle des deux s'applique est convenue par mission. |
| Que m'est-il transféré à la fin ? | 100% du code, de la propriété intellectuelle et de l'infrastructure, par écrit. Sans licence par utilisateur sur ce qui a été construit pour vous. |
À cela s'ajoute le point qui vient en premier en Allemagne et en Suisse : aucun code client et aucune donnée client ne part vers l'Inde si votre contrat ne l'autorise pas explicitement. Si le contrat est muet, la réponse est non. Lorsqu'un transfert est convenu, il s'appuie sur des clauses contractuelles types. Nous construisons en tenant compte du RGPD et de la nLPD suisse révisée, et l'hébergement des données en Suisse ou dans l'UE est disponible sur demande.
À quoi ressemble une collaboration sérieuse
Un NDA est signé avant la première conversation technique. Ensuite le premier atelier et une première estimation : gratuits, et généralement rendus sous trois jours ouvrés.
Le vrai point de départ est un sprint de cadrage payant, une à deux semaines, $2,900–4,900, intégralement déduit du budget de réalisation. Il se termine par un périmètre écrit, une architecture, une feuille de route chiffrée et la liste de ce que nous nous engageons explicitement à ne pas construire. Le prix ferme en découle.
À partir d'une offre signée, il s'écoule quatre à cinq jours ouvrés jusqu'au premier sprint. Chaque modification passe par une revue senior. Nos collègues commerciaux en Suisse travaillent en français et en allemand, le développement se fait en anglais. Les clients suisses peuvent contracter sous droit suisse comme droit applicable aux litiges, une option contractuelle par mission. CODT reste une société indienne de type private limited.
Un système construit en Inde qui ne réside pas en Inde
La réponse la plus concrète à « l'Inde est un risque pour la protection des données », c'est une architecture. Nous avons construit LeadTrack AI, une plateforme multi-tenant d'agents vocaux IA, depuis ici ; le client est à Melbourne et les données résident sur AWS Sydney. Plus de 100 000 appels réels ont transité par le système depuis, le premier appel part en moins de 30 secondes, et la conversion des leads qualifiés a progressé de 38%.
Où l'on construit et où résident les données sont deux décisions distinctes. Gurugram et Sydney figurent dans deux colonnes différentes du même contrat.
Ce que cela coûte, et ce que le prix n'est pas
Une première version en production issue de notre développement d'applications va de $30,000–55,000 pour un MVP léger à $120,000–250,000+ pour une plateforme complexe, selon le périmètre. Le détail des vrais facteurs de coût figure dans l'article sur les coûts, et vous pouvez vous faire une idée avec le calculateur de coût. Fourchettes indicatives 2026, pas une offre ; le prix ferme vient après le sprint de cadrage payant.
Ce que je dirai tout de même, même si cela ne sert pas la vente : si le prix est votre seul critère, vous trouverez en Inde des prestataires qui chiffrent en dessous de nous. Ces offres existent, et il leur arrive de gagner contre nous. Nous ne sommes pas la version économique d'un prestataire européen, mais une équipe senior avec une structure de coûts indienne. La deuxième année, vous voyez la différence au temps qu'il faut à un nouveau développeur avant de pouvoir toucher votre code sans danger.
Quand ne pas faire développer en Inde
Si vous avez besoin d'un prototype jetable pour un pitch dans six semaines, que personne ne touchera ensuite : prenez l'offre la moins chère que vous trouverez. Vraiment. Un sprint de cadrage pour quelque chose qui n'ira jamais en production est de l'argent perdu, et je n'ai pas envie de vous en vendre un.
Si vos exigences naissent de discussions devant l'écran plutôt que de documents, et qu'il faut pour cela quelqu'un dans la pièce deux fois par semaine, prenez le studio à Genève ou à Zurich. Nous pourrions gagner ce projet. Vous n'en seriez pas satisfait.
Le troisième cas est celui que je vois le plus souvent, et il n'a rien à voir avec l'Inde : personne chez vous n'a une demi-heure par jour à consacrer aux décisions. L'équipe attend. Le tableau ne bouge plus. Le sprint est payé quand même. Dans ce cas, décalez plutôt le démarrage.
Pour tout ce qui se situe entre les deux, la localisation est exactement ce qu'elle doit être : une question à laquelle on répond une fois, puis que l'on referme. Nous avons détaillé tout cela pour les entreprises suisses, et chiffré la comparaison entre l'Inde et l'Europe de l'Est. Si vous préférez parler de votre projet : écrivez-nous ce que vous voulez construire. Vous recevrez sous un jour ouvré un avis clair : oui ou non, sommes-nous le bon partenaire pour ce projet.
