ExternalisationRGPDForfaitSur-mesureContrat
Externaliser le développement de votre logiciel : options, risques et contrat
9 min de lecture
Externaliser le développement d'un logiciel métier, c'est confier sa construction à une équipe qui n'est pas la vôtre : un freelance, une ESN, une agence, un studio, en France ou à l'étranger. C'est souvent la seule option raisonnable pour une PME qui n'a pas d'équipe technique, et rarement un mauvais choix en soi. Les projets qui tournent mal ne souffrent pas d'avoir été externalisés : ils souffrent d'avoir été mal contractualisés, mal pilotés ou confiés au mauvais type de prestataire.
Cet article s'adresse au dirigeant d'une entreprise établie qui veut faire construire un outil métier. Si votre question est plutôt de savoir qui porte la technique d'une startup sur la durée (CTO associé, CTO à temps partagé ou studio), elle est traitée dans notre article sur le CTO externalisé.
Pourquoi externaliser plutôt que recruter
Recruter une équipe de développement a du sens quand le logiciel est votre produit, ou qu'il évolue chaque semaine pendant des années. Pour un outil métier, l'équation est différente.
- Un seul développeur ne suffit pas. Un logiciel en production demande de la conception, du développement, de la sécurité, de l'hébergement et de la maintenance. Une personne seule couvre rarement tout, et son départ met le projet à l'arrêt.
- La charge n'est pas constante. Un projet demande beaucoup de travail pendant quelques mois, puis un rythme de maintenance beaucoup plus faible.
- Le recrutement prend du temps, et il faut savoir évaluer un profil technique quand on n'en a pas soi-même.
Externaliser répond à ces trois contraintes. En échange, vous dépendez d'un tiers. Tout l'enjeu est de rendre cette dépendance réversible.
Les quatre façons d'externaliser
| Option | Ce que vous achetez | Qui porte le risque de dérive | Point de vigilance |
|---|---|---|---|
| Développeur freelance | Du temps d'une personne | Vous | Continuité si la personne s'en va |
| ESN en régie | Des jours de développeurs mis à disposition | Vous | Pilotage quotidien à assurer de votre côté |
| Agence ou studio au forfait | Un résultat défini, à prix fixe | Le prestataire | Qualité de la définition du périmètre |
| Équipe offshore ou nearshore | Du temps ou un résultat, à taux plus bas | Selon le contrat | Décalage horaire, droit applicable, transferts de données |
Freelance et régie : vous achetez du temps
En régie comme avec un freelance facturé au jour, vous payez des jours de travail. Si le projet prend deux fois plus de temps que prévu, vous payez deux fois plus. Ce modèle convient quand vous savez piloter une équipe technique et que le besoin évolue sans cesse. Il convient mal à une PME sans compétence technique interne, qui se retrouve à diriger des développeurs sans savoir juger leur travail.
La régie a aussi une limite juridique peu connue : le Code du travail interdit toute opération à but lucratif ayant pour objet exclusif le prêt de main-d'œuvre (article L8241-1 du Code du travail), hors des cadres qu'il prévoit. Une prestation de régie doit donc rester une prestation de service, avec un encadrement assuré par le prestataire. Les repères de prix journaliers et la différence entre les modèles sont détaillés dans notre article sur le TJM d'un développeur.
Forfait : vous achetez un résultat
Au forfait, le prestataire s'engage sur un périmètre, un prix et un délai. Le risque de dépassement passe de son côté, ce qui l'oblige à cadrer sérieusement avant de signer. La contrepartie est qu'un périmètre mal décrit produit soit un devis gonflé par la prudence, soit un litige à la recette. La comparaison complète est dans forfait ou régie pour un logiciel métier.
Offshore et nearshore : un taux plus bas, d'autres coûts
Confier le développement à une équipe en Inde, au Maghreb ou en Europe de l'Est réduit le taux horaire. La page de tarifs de Clutch le résume ainsi : embaucher aux États-Unis ou en Europe de l'Ouest coûte nettement plus cher qu'en Europe de l'Est ou en Asie du Sud-Est. C'est l'argument honnête de l'offshore.
Le coût total comprend pourtant d'autres lignes : votre temps de pilotage, les allers-retours sur des malentendus, le décalage horaire (l'Inde a 3 h 30 à 4 h 30 d'avance sur Paris selon la saison), le droit applicable en cas de litige et, si des données personnelles sortent de l'Union européenne, le cadre des transferts internationaux du RGPD. L'offshore fonctionne bien quand vous avez en interne quelqu'un capable de piloter et de relire. Sans cette personne, l'économie sur le taux se perd souvent dans les reprises.
Ce que le RGPD vous impose, quel que soit le prestataire
Externaliser délègue le travail, pas la responsabilité. Si l'application traite des données personnelles (clients, salariés, candidats), vous restez responsable du traitement, et le prestataire devient votre sous-traitant au sens du RGPD.
L'article 28 du RGPD exige alors un contrat écrit qui précise notamment les instructions du responsable, les mesures de sécurité, la confidentialité, le recours à d'autres sous-traitants et le sort des données en fin de contrat. La CNIL publie un guide du sous-traitant, en questions-réponses, avec un exemple de clauses à adapter (édition de 2017). Un prestataire sérieux aborde le sujet de lui-même ; s'il ne le fait pas, posez la question.
Un prestataire établi dans l'Union, qui héberge les données dans l'Espace économique européen, vous épargne une couche entière d'analyse : les règles sur les transferts hors de l'Union (chapitre V du RGPD) ne s'appliquent pas à ce traitement.
Ce qu'il ne faut jamais externaliser
Le développement s'externalise. Trois choses restent chez vous.
- La décision. Un interlocuteur nommé, avec le mandat d'arbitrer le périmètre et de valider les livraisons. Quand cinq personnes valident, personne ne valide.
- La connaissance du métier. Le prestataire apprend votre activité ; il ne la remplace pas. Vos utilisateurs doivent être disponibles pour les démonstrations et la recette.
- Les accès. Hébergement, nom de domaine, dépôt de code, comptes de paiement et de services tiers : ouverts à votre nom, ou transférables par une clause explicite. Le jour où vous changez de prestataire, c'est ce point qui décide si vous gardez votre logiciel. Notre article sur la réversibilité détaille ce qu'il faut prévoir.
Les clauses qui comptent dans le contrat
- Le périmètre, décrit de façon vérifiable : écrans, règles, connexions, reprise de données.
- Les critères de recette, écrits avant le développement. Sans eux, « terminé » veut dire ce que chaque partie veut qu'il dise.
- La gestion des changements : toute demande nouvelle passe par un avenant chiffré, pas par une extension silencieuse.
- La propriété intellectuelle : ce qui vous est cédé, ou concédé, et à quelles conditions. Chez nous, ces droits sont définis au cas par cas dans le contrat, selon la formule retenue.
- La vie après la mise en production : hébergement, sauvegardes, mises à jour de sécurité, corrections, délais d'intervention.
- La réversibilité : documentation, transfert des accès et du code, aide à la reprise par une autre équipe.
Rendre visible ce que vous achetez
Le malentendu le plus coûteux d'une externalisation naît d'un document que chacun lit à sa manière. Une phrase comme « le responsable valide la commande » peut désigner un bouton ou un circuit d'approbation à deux niveaux, et le prestataire chiffre l'une des deux lectures.
Le moyen le plus sûr de l'éviter est de voir l'application avant de signer. Un prototype visuel, avec les écrans réels et des données qui ressemblent aux vôtres, ferme le périmètre en le montrant. C'est ce qui permet ensuite un prix fixe tenable. Nous expliquons dans voir son logiciel avant de le payer ce qu'un prototype prouve, et ce qu'il ne remplace pas.
La liste de vérification avant de signer
- L'entreprise existe-t-elle vraiment ? L'annuaire des entreprises de l'État affiche gratuitement son immatriculation et ses dirigeants.
- Qui travaillera concrètement sur le projet, et est-ce la même équipe que celle de l'avant-vente ?
- Où seront hébergées les données, et par quels sous-traitants ?
- Un contrat de sous-traitance RGPD est-il prévu ?
- Que vous est-il remis à la fin : code, documentation, accès ?
- Une autre équipe pourrait-elle reprendre le logiciel demain ?
- Le prestataire exploite-t-il ses propres logiciels en production ? Une équipe qui maintient ses propres produits sait ce que coûte réellement l'après-livraison.
Notre façon de travailler
LPR Studio est une SAS basée à Rennes. Nous concevons, développons, déployons et maintenons des applications métier, et nous éditons et exploitons nos propres logiciels en production, comme Izi-Devis, une application de devis et de factures pour les artisans du bâtiment. Nous ne vendons ni heures ni personnel : pas de régie. Chaque projet commence par un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés, qui n'est ni payé ni livré. Vous choisissez ensuite la formule qui vous convient : forfait à prix fixe, abonnement sans payer le développement, ou édition d'un SaaS.