Prestataire tech : 7 vérifications

Vous signez avec une agence ou un freelance pour construire votre SaaS. Le devis vous paraît clair et les échanges se passent bien. Six mois plus tard, vous découvrez que le dépôt Git appartient au prestataire, que le cloud est payé depuis son compte et que personne n'a prévu comment récupérer les données en cas de séparation. Le produit fonctionne. Pourtant, votre entreprise n'en a pas vraiment le contrôle.

J'ai découvert ce risque en 2019, en me retrouvant de l'autre côté. J'avais mis à disposition d'un client des modules de réservation et de paiement développés pour mes propres projets. Le client pouvait les exploiter dans sa marketplace, mais je ne lui en avais pas transféré la propriété. Lorsqu'il a confié la suite du projet à une agence, l'ensemble du code lui a été transmis. Mes modules ont ensuite été modifiés sans mon accord.

Le client ne cherchait pas à me léser. L'agence pensait probablement pouvoir reprendre ce qu'on lui avait confié. Personne n'avait pris le temps de distinguer ce qui appartenait au client, ce qu'il pouvait modifier et ce qui restait ma propriété. Depuis, je préfère régler ces questions avant la première ligne de code.

Un bon contrat évite les suppositions

Quand j'évalue un prestataire, je regarde évidemment le tarif et le délai. Mais je veux aussi savoir ce que l'entreprise gardera entre ses mains une fois le projet livré : le code, les accès et la connaissance nécessaire pour continuer.

La confiance facilite le quotidien. Deux ans plus tard, quand les équipes ont changé, elle ne permet plus de retrouver un accord qui n'a jamais été écrit.

Et le coût tombe rarement au bon moment. Un incident survient, le prestataire part, une équipe interne arrive ou un investisseur pose une question précise. Le produit fonctionne encore, mais personne ne sait le transmettre. Une clause négligée finit par bloquer la roadmap, un client ou une levée.

Le code source est protégé par le droit d'auteur. En France, l'INPI rappelle que le logiciel et son code source sont des œuvres de l'esprit. Une cession ne devrait donc jamais tenir dans une formule vague. L'article L131-3 du Code de la propriété intellectuelle prévoit que les droits cédés soient mentionnés distinctement et que leur domaine d'exploitation soit délimité.

Vous n'avez pas à devenir juriste. Repérez les zones floues avec cette checklist, puis faites relire les clauses sensibles par un professionnel du droit.

Les sept vérifications avant de signer

Ce que vous achetez réellement

1. Le périmètre et la définition de la livraison

Sur le papier, un devis peut énumérer des écrans sans expliquer ce qui sera vraiment livré. Vérifiez s'il inclut le code source, les tests, la documentation, la migration des données et la mise en production. Qui valide chaque étape ? Selon quels critères ?

Une fonctionnalité visible pendant une démonstration n'est pas forcément prête pour de vrais clients. Le contrat doit dire où s'arrête la démo, quand commence la mise en production et ce que couvre la période de correction.

La question que je pose est simple : que pourra réellement faire votre équipe le lendemain de la livraison ? Les oublis du devis apparaissent assez vite.

2. Les droits sur le code et les composants préexistants

Quatre verbes permettent de sortir du flou : utiliser, modifier, commercialiser et transmettre. Le contrat doit répondre pour chacun d'eux, en séparant le code créé pour votre projet des briques que le prestataire possédait déjà.

Un freelance peut légitimement réutiliser une bibliothèque générique, comme je l'avais fait en 2019. Votre continuité dépend alors des droits prévus sur cette brique. Faites aussi l'inventaire des composants open source et des services tiers dont les licences ou abonnements conditionnent le produit.

Cet inventaire peut tenir dans une annexe ou dans la documentation. Vous verrez tout de suite ce qui peut être transmis librement et ce qui dépend encore d'un tiers.

Ce que votre entreprise doit contrôler

3. La propriété des comptes critiques

Le dépôt Git, le nom de domaine, le cloud, la base de données et les paiements doivent être rattachés à l'entreprise. Le prestataire y travaille avec ses propres accès. Il ne devient pas pour autant le propriétaire qu'il faudra rappeler dans l'urgence.

Vérifiez le titulaire du compte principal, son adresse de récupération et son moyen de paiement. Nommez aussi une seconde personne côté entreprise capable de reprendre la main pendant un incident.

Votre prestataire peut tout à fait configurer ces services. Faites simplement créer les comptes au nom de l'entreprise, puis donnez-lui des accès que vous pourrez révoquer.

4. Les accès à la production et la séparation des environnements

Un développeur peut avoir besoin d'intervenir sur la vraie application. Donner cet accès ne signifie pas distribuer un trousseau passe-partout à toute l'équipe.

Demandez si les changements sont d'abord vérifiés dans un environnement de test, séparé de l'application et des données clients. Les accès à la production doivent être nominatifs, protégés et supprimés au départ d'un intervenant. La CNIL recommande aussi de tracer les opérations de maintenance et d'identifier leurs auteurs.

Le détail des outils peut rester du côté technique. En tant que fondateur, vous devez obtenir une réponse compréhensible à deux questions : qui peut toucher aux vraies données, et comment le saurez-vous après une intervention ?

5. Les données, les sauvegardes et leur restitution

Si le prestataire accède aux données clients, demandez lesquelles, pourquoi, où elles sont stockées et qui peut encore les traiter. Lorsqu'il agit comme sous-traitant au sens du RGPD, la CNIL rappelle que le contrat doit encadrer les obligations de chaque partie.

Prévoyez aussi le format et le délai de restitution en fin de mission. Posez ensuite trois questions : où sont les sauvegardes, qui peut restaurer les données et quand le dernier test a-t-il eu lieu ? Cet article détaille ce contrôle.

Testez au moins une fois l'export des données. Si le fichier est incomplet ou impossible à relire, mieux vaut le découvrir pendant que la collaboration se passe bien.

Ce qui rend le changement possible

6. La documentation et le transfert de connaissance

Une documentation exhaustive sera vite obsolète. À l'autre extrême, tout garder dans la tête du prestataire rend le produit impossible à reprendre.

Je demande un socle plus modeste : lancer le projet, déployer une version, restaurer les données et renouveler les clés d'API ou identifiants techniques. Puis je fais suivre la procédure par une personne qui n'a pas construit le système. Si elle doit appeler son auteur, la transmission reste incomplète.

Je préfère ce test à un dossier de cinquante pages que personne n'ouvrira après la livraison.

7. La réversibilité et les conditions de sortie

Une collaboration peut bien se passer et quand même prendre fin. Vos besoins changent, le prestataire évolue ou vous recrutez une équipe interne. Mieux vaut avoir fixé le préavis, les livrables de sortie et le coût de l'accompagnement avant d'en avoir besoin.

La remise doit couvrir les dépôts, les accès, les exports de données, la documentation et les travaux en cours. Une archive ZIP reçue le dernier jour ne suffit pas : une autre équipe doit pouvoir reprendre le produit dans des conditions raisonnables.

Fixez aussi le délai de cette transmission et son coût. Sans ces deux éléments, une clause de réversibilité peut rester correcte sur le papier mais inutilisable dans l'urgence.

Les signaux qui doivent vous faire ralentir

Un bon prestataire n'aura pas toujours une réponse immédiate. Il doit pouvoir clarifier ces sujets sans traiter chaque question comme une preuve de défiance.

Je ralentirais si le dépôt doit rester exclusivement sur son compte, si les droits cédés tiennent dans une phrase ambiguë ou si la documentation est repoussée à « plus tard ». Même prudence quand le devis ne dit rien des données ou de la sortie de mission.

Un prix bas peut s'expliquer par un socle ou des services mutualisés. Ce choix reste rationnel si vous en connaissez les conséquences. La qualité des réponses montre rapidement où commence votre autonomie et où elle s'arrête.

Transformer la checklist en cadre de collaboration

Je préfère aborder ces vérifications pendant le cadrage, avec le budget et le planning. Pour chaque point, une page suffit : ce qui appartient à l'entreprise, ce qui reste chez le prestataire, le responsable et la date de transmission.

Un prototype sans donnée réelle peut fonctionner avec un cadre léger. Un SaaS qui encaisse des paiements ou porte un contrat B2B mérite plus de précision. Des responsabilités explicites permettent ensuite au prestataire de travailler sans surveillance permanente.

Si personne dans l'entreprise ne peut mener cette revue, un CTO part-time peut cadrer les responsabilités techniques et préparer les questions à soumettre au juriste.

Faites relire le contrat par un juriste lorsque les enjeux de propriété intellectuelle, de données personnelles ou de responsabilité deviennent importants.

Ce qu'il faut retenir

Définissez ce qui sera réellement livré et distinguez le code créé pour votre projet des composants préexistants, des logiciels open source et des services tiers. Les comptes critiques doivent appartenir à l'entreprise, qui délègue ensuite au prestataire les accès nécessaires à son travail.

Prévoyez aussi la restitution des données, la documentation et les conditions de sortie. Vous aurez une relation plus saine si personne n'a besoin de deviner ses responsabilités. Pour les clauses sensibles, faites tout de même valider le contrat par un juriste.

Questions fréquentes

Le code développé appartient-il automatiquement au client ?

Ne partez pas de cette hypothèse. Le code source est protégé par le droit d'auteur et les droits transmis dépendent notamment du contrat et du contexte de création. Faites préciser par écrit ce que votre entreprise peut exploiter, modifier, commercialiser et transmettre, puis demandez une validation juridique adaptée à votre situation.

L'entreprise doit-elle posséder tous les comptes techniques ?

Elle doit au minimum contrôler les comptes dont dépend la continuité du produit : dépôt de code, domaine, cloud, base de données, paiement et services essentiels. Le prestataire peut disposer de droits étendus pour travailler sans devenir le propriétaire du compte principal.

Un contrat détaillé suffit-il à garantir la réversibilité ?

Non. Le contrat crée une obligation, mais seule une transmission testée prouve qu'une autre équipe peut reprendre le produit. Faites vérifier les accès, l'export des données, la documentation et une procédure de déploiement avant la fin de la mission.

Conclusion

Avant de signer, vérifiez une chose simple : si ce prestataire disparaissait dans six mois, votre entreprise pourrait-elle continuer à exploiter, maintenir et faire évoluer son produit ?

Si la réponse dépend d'un mot de passe, d'un compte ou d'un accord encore flou, réglez-le maintenant. Et si vous voulez un regard indépendant avant d'engager votre SaaS, réservez un échange de 30 minutes.