This is practical guidance, not legal advice. Have a lawyer review any contract of real value, and check how these points work under the law that applies to you.

Why contracts matter more than trust

Most relationships with developers and agencies are good. The contract is not for those. It is for the day the provider is unavailable, the relationship sours, or the company is sold. At that point, what is written is what you get, and what is missing is up for negotiation at the worst possible time.

Clause 1: Ownership of deliverables

What to ask for: the code, designs, documentation and data created for you belong to you, or you hold a licence broad enough to use, modify and have others maintain it.

Points to check:

• When ownership transfers: on creation, on delivery, or on full payment. "On full payment" is common and fair, but make sure it is stated.
• Scope: does it cover source code, not only the running application?
• Pre-existing tools: providers often reuse their own libraries and frameworks. That is normal, but the contract should say you get a licence to use them as part of the deliverable, without extra fees and without time limits.
• Third-party and open source components: the provider should list them, and none should carry licence terms that conflict with your intended use.
• Moral rights and freelancer contributors: if subcontractors work on your project, the provider must ensure they have transferred their rights too.

A vague "the client receives the final product" is not enough. "The client receives the source code" is.

Clause 2: Accounts, hosting and keys in your name

What to ask for: every account that matters (hosting, domain, repositories, third-party services, payment providers) is created in your name or transferred to it, with you as owner and the provider as a limited user.

Points to check:

• Domain registrant is you
• Cloud, hosting and repository accounts belong to your organisation
• Third-party licences are registered to you
• Billing goes to you directly, not through re-invoicing with a margin you cannot see
• Secrets and credentials are stored where you control them

If a provider insists on hosting everything in their own account "for convenience", ask what happens on the day you leave. The same four columns as in the 30-minute account audit help you keep track.

Clause 3: Delivery of source code and deployment documentation

What to ask for: at each milestone and at the end, the source code is delivered or accessible in a repository you own, along with the documentation needed to build, deploy and operate it.

Define "documentation" so it is not a matter of opinion:

• How to run it locally
• How to build and deploy
• Configuration and environment variables (names and purposes, not secrets)
• Architecture overview
• List of external services and dependencies
• Backup and restore procedure
• Known limitations

Clause 4: Exit and handover

What to ask for: a defined handover process if the contract ends, for any reason.

Include:

• A notice period
• A number of support hours (or a rate) for knowledge transfer
• Removal of the provider's access once the handover is done
• Transfer of third-party contracts that can be transferred, and a list of those that cannot
• An exit plan document

Clause 5: No withholding of access during disputes

What to ask for: access to your systems, data and accounts is not suspended or withheld because of a disagreement about an invoice or scope. Disputes go through the normal channels: discussion, mediation, courts.

This protects you from the situation where your website goes offline in the middle of a negotiation. A good provider also benefits, because it protects them from accusations of holding you hostage.

Clause 6: Scope, acceptance and changes

Many conflicts are about what was promised.

• Scope: a written description of what is included, and a list of what is excluded
• Acceptance criteria: how you will decide that a deliverable is done (tests, a demo, a checklist) and how long you have to review it
• Change requests: how changes are proposed, priced and approved in writing, before work starts
• Warranty period: a period after delivery during which the provider fixes defects at no charge, with a definition of what counts as a defect versus a new request

Clause 7: Payment terms

• Payment schedule tied to milestones, not only to dates
• Deposit size (a moderate amount is normal, a large upfront payment for work that has not started is a risk)
• Late payment terms in both directions
• Expenses and third-party costs: who pays, and what needs prior approval
• Whether the quote is a fixed price or an estimate, and what happens when it is exceeded

Clause 8: Confidentiality and data protection

• Confidentiality obligations on both sides, surviving the end of the contract
• If the provider processes personal data on your behalf, a data processing agreement that covers purposes, security measures, subprocessors, location of processing and deletion at the end
• A requirement to notify you promptly of a security incident
• Rules for using production data in test environments (see GDPR and test environments)

Clause 9: Security expectations

• Basic obligations: access limited to those who need it, strong authentication, no sharing of credentials, secure handling of secrets
• Responsibility for the security of what is delivered: at least reasonable standard practices, and how vulnerabilities discovered after delivery are handled
• Whether security updates are included in maintenance

Clause 10: Maintenance and support

If the provider will keep running your system:

• What is included (updates, monitoring, backups, bug fixes) and what is not
• Response and resolution times, and the hours they apply to
• Availability targets, if relevant, and what happens when they are missed
• How to reach the provider in an emergency
• Price and how it can change
• Whether you can terminate maintenance separately from the rest, and with what notice

A maintenance contract you cannot leave without penalty is a form of lock-in.

Clause 11: Subcontracting and continuity

• Whether the provider can subcontract, and whether they must tell you
• That subcontractors are bound by the same obligations
• What happens if the person who built your system becomes unavailable: is there a second person who knows it? Is documentation enough for someone else to continue?
• What happens if the provider's company is sold or closes

Clause 12: Use of AI tools

This is increasingly worth stating:

• Whether the provider may use AI tools in the work
• That generated code is reviewed by a person before delivery
• That your confidential data and source code are not sent to tools whose terms allow training on it, or are not sent at all, depending on your requirements
• That the provider remains responsible for the quality and licensing of what they deliver

The same principle as when you add AI to your own processes without handing over the keys: control the accounts, limit what leaves your perimeter, and keep a human accountable for the result.

Clause 13: Liability and termination

• A cap on liability that is realistic relative to the project, and what is excluded from the cap
• Termination for convenience: can either side stop with notice, and what is payable for work done?
• Termination for breach: what counts, and what cure period applies?
• What survives termination (confidentiality, ownership, handover)

Red flags in a contract

• You do not own the code, or ownership is "to be discussed"
• Hosting and accounts are in the provider's name, with no transfer clause
• Handover and exit are not mentioned
• Heavy penalties for leaving, or long automatic renewals
• Access can be suspended at the provider's discretion
• Ownership transfers only after "all obligations are fulfilled", with no definition
• Vague scope with a fixed price, or an open-ended estimate with no cap or review points
• The provider refuses to discuss any change to the standard terms

Standard terms can often be adjusted if you ask. Providers who refuse every change, even reasonable ones, are telling you something.

How to negotiate without souring things

• Present these as standard good practice, not as a sign of distrust
• Explain that they protect both sides, including the provider's reputation
• Prioritise: ownership, accounts, exit and no-withholding matter most
• Offer something in return: clear scope, prompt payment, a reasonable handover fee
• Get agreements in writing, even for small projects

Checklist

• Ownership of code, designs and documentation defined, with timing
• Third-party and open source components listed
• Accounts, domains and keys in our name
• Source code and documentation delivered at milestones
• Exit and handover process defined
• Access not withheld during disputes
• Scope, acceptance and change process written
• Payment tied to milestones
• Data protection and security obligations stated
• Maintenance terms and termination conditions clear
• Subcontracting and continuity addressed
• AI tool usage addressed
• Reviewed by a lawyer if the project is significant

Ce texte est un guide pratique, pas un conseil juridique. Faites relire par un avocat tout contrat d'enjeu réel, et vérifiez comment ces points s'appliquent sous le droit qui vous concerne.

Pourquoi le contrat compte plus que la confiance

La plupart des relations avec des développeurs et des agences se passent bien. Le contrat n'est pas pour celles-là. Il sert le jour où le prestataire devient injoignable, où la relation se dégrade, ou où l'entreprise est vendue. À ce moment-là, ce qui est écrit est ce que vous obtenez, et ce qui manque se négocie au pire moment possible.

Clause 1: Propriété des livrables

Ce qu'il faut demander: le code, les maquettes, la documentation et les données créés pour vous vous appartiennent, ou vous disposez d'une licence assez large pour les utiliser, les modifier et les faire maintenir par d'autres.

Points à vérifier:

• Moment du transfert: à la création, à la livraison, ou au paiement intégral. « Au paiement intégral » est courant et équitable, mais il faut que ce soit écrit.
• Périmètre: cela couvre-t-il le code source, pas seulement l'application en production ?
• Outils préexistants: les prestataires réutilisent souvent leurs propres bibliothèques et frameworks. C'est normal, mais le contrat doit préciser que vous obtenez une licence pour les utiliser dans le livrable, sans frais supplémentaires et sans limite de durée.
• Composants tiers et open source: le prestataire doit les lister, et aucun ne doit porter des termes de licence incompatibles avec votre usage prévu.
• Droits moraux et contributeurs freelances: si des sous-traitants travaillent sur votre projet, le prestataire doit s'assurer qu'ils ont aussi cédé leurs droits.

Un vague « le client reçoit le produit final » ne suffit pas. « Le client reçoit le code source » oui.

Clause 2: Comptes, hébergement et clés à votre nom

Ce qu'il faut demander: chaque compte qui compte (hébergement, domaine, dépôts, services tiers, prestataires de paiement) est créé à votre nom ou vous est transféré, avec vous comme propriétaire et le prestataire comme utilisateur limité.

Points à vérifier:

• Le titulaire du domaine, c'est vous
• Les comptes cloud, d'hébergement et de dépôt appartiennent à votre organisation
• Les licences tierces sont enregistrées à votre nom
• La facturation vous arrive directement, pas via une refacturation avec une marge opaque
• Les secrets et identifiants sont stockés là où vous les contrôlez

Si un prestataire insiste pour tout héberger sur son compte « par commodité », demandez ce qui se passe le jour où vous partez. Les quatre colonnes de l'audit de comptes en 30 minutes aident à garder le fil.

Clause 3: Livraison du code source et de la documentation de déploiement

Ce qu'il faut demander: à chaque jalon et à la fin, le code source est livré ou accessible dans un dépôt que vous possédez, avec la documentation nécessaire pour builder, déployer et exploiter.

Définissez « documentation » pour que ce ne soit pas une question d'opinion:

• Comment le faire tourner en local
• Comment builder et déployer
• Configuration et variables d'environnement (noms et rôles, pas les secrets)
• Vue d'ensemble de l'architecture
• Liste des services externes et dépendances
• Procédure de sauvegarde et de restauration
• Limitations connues

Clause 4: Sortie et passation

Ce qu'il faut demander: une procédure de passation définie si le contrat se termine, pour quelque raison que ce soit.

À inclure:

• Un préavis
• Un nombre d'heures de support (ou un tarif) pour le transfert de connaissance
• Le retrait des accès du prestataire une fois la passation faite
• Le transfert des contrats tiers transférables, et la liste de ceux qui ne le sont pas
• Un document de plan de sortie

Clause 5: Pas de rétention d'accès pendant un litige

Ce qu'il faut demander: l'accès à vos systèmes, données et comptes n'est ni suspendu ni retenu à cause d'un désaccord sur une facture ou le périmètre. Les litiges passent par les voies normales: discussion, médiation, tribunaux.

Cela vous protège du cas où votre site tombe au milieu d'une négociation. Un bon prestataire y gagne aussi, parce que cela le protège de l'accusation de vous prendre en otage.

Clause 6: Périmètre, recette et évolutions

Beaucoup de conflits portent sur ce qui a été promis.

• Périmètre: une description écrite de ce qui est inclus, et une liste de ce qui est exclu
• Critères d'acceptation: comment vous décidez qu'un livrable est terminé (tests, démo, checklist) et combien de temps vous avez pour le relire
• Demandes de changement: comment les évolutions sont proposées, chiffrées et approuvées par écrit, avant le démarrage des travaux
• Période de garantie: une durée après livraison pendant laquelle le prestataire corrige les défauts sans frais, avec une définition de ce qui compte comme défaut versus nouvelle demande

Clause 7: Conditions de paiement

• Échéancier de paiement lié aux jalons, pas seulement aux dates
• Montant de l'acompte (un montant modéré est normal, un gros paiement d'avance pour un travail non commencé est un risque)
• Pénalités de retard dans les deux sens
• Frais et coûts tiers: qui paie, et ce qui nécessite une validation préalable
• Si le devis est un prix forfaitaire ou une estimation, et ce qui se passe en cas de dépassement

Clause 8: Confidentialité et protection des données

• Obligations de confidentialité des deux côtés, qui survivent à la fin du contrat
• Si le prestataire traite des données personnelles pour votre compte, un accord de traitement qui couvre les finalités, les mesures de sécurité, les sous-traitants, le lieu de traitement et la suppression en fin de contrat
• Une obligation de vous notifier rapidement un incident de sécurité
• Des règles pour l'usage de données de production en environnement de test (voir RGPD et environnements de test)

Clause 9: Attentes de sécurité

• Obligations de base: accès limité à ceux qui en ont besoin, authentification forte, pas de partage d'identifiants, gestion sécurisée des secrets
• Responsabilité pour la sécurité de ce qui est livré: au minimum des pratiques raisonnables, et la façon dont les vulnérabilités découvertes après livraison sont traitées
• Si les mises à jour de sécurité sont incluses dans la maintenance

Clause 10: Maintenance et support

Si le prestataire continue d'exploiter votre système:

• Ce qui est inclus (mises à jour, monitoring, sauvegardes, corrections) et ce qui ne l'est pas
• Délais de réponse et de résolution, et les plages horaires concernées
• Objectifs de disponibilité, si pertinent, et ce qui se passe en cas de manquement
• Comment joindre le prestataire en urgence
• Le prix et comment il peut évoluer
• Si vous pouvez résilier la maintenance séparément du reste, et avec quel préavis

Un contrat de maintenance qu'on ne peut pas quitter sans pénalité est une forme de lock-in.

Clause 11: Sous-traitance et continuité

• Si le prestataire peut sous-traiter, et s'il doit vous en informer
• Que les sous-traitants sont tenus aux mêmes obligations
• Ce qui se passe si la personne qui a construit votre système devient indisponible: y a-t-il une seconde personne qui le connaît ? La documentation suffit-elle à un tiers pour continuer ?
• Ce qui se passe si l'entreprise du prestataire est vendue ou ferme

Clause 12: Usage d'outils d'IA

De plus en plus utile à écrire:

• Si le prestataire peut utiliser des outils d'IA dans le travail
• Que le code généré est relu par une personne avant livraison
• Que vos données confidentielles et votre code source ne sont pas envoyés à des outils dont les conditions permettent l'entraînement dessus, ou ne sont pas envoyés du tout, selon vos exigences
• Que le prestataire reste responsable de la qualité et des licences de ce qu'il livre

Même principe que lorsque vous branchez une IA sur vos process sans lui donner les clés: contrôler les comptes, limiter ce qui sort de votre périmètre, et garder un humain responsable du résultat.

Clause 13: Responsabilité et résiliation

• Un plafond de responsabilité réaliste par rapport au projet, et ce qui en est exclu
• Résiliation pour convenance: chaque partie peut-elle arrêter avec préavis, et que paie-t-on pour le travail fait ?
• Résiliation pour manquement: qu'est-ce qui compte, et quel délai de remède s'applique ?
• Ce qui survit à la résiliation (confidentialité, propriété, passation)

Signaux d'alerte dans un contrat

• Vous ne possédez pas le code, ou la propriété est « à discuter »
• L'hébergement et les comptes sont au nom du prestataire, sans clause de transfert
• Passation et sortie ne sont pas mentionnées
• Pénalités lourdes pour partir, ou reconductions automatiques longues
• L'accès peut être suspendu à la discrétion du prestataire
• La propriété ne se transfère qu'après « toutes les obligations remplies », sans définition
• Périmètre vague avec prix forfaitaire, ou estimation ouverte sans plafond ni points de revue
• Le prestataire refuse toute discussion sur ses conditions générales

Les conditions standard se négocient souvent si on le demande. Un prestataire qui refuse tout changement, même raisonnable, vous donne une information utile.

Négocier sans tendre la relation

• Présentez ces points comme une bonne pratique courante, pas comme un signe de méfiance
• Expliquez qu'ils protègent les deux côtés, y compris la réputation du prestataire
• Priorisez: propriété, comptes, sortie et non-rétention d'accès comptent le plus
• Proposez quelque chose en retour: périmètre clair, paiement rapide, frais de passation raisonnables
• Obtenez les accords par écrit, même pour les petits projets

Checklist

• Propriété du code, des maquettes et de la documentation définie, avec le moment du transfert
• Composants tiers et open source listés
• Comptes, domaines et clés à notre nom
• Code source et documentation livrés aux jalons
• Processus de sortie et de passation défini
• Accès non retenus pendant un litige
• Périmètre, recette et process de changement écrits
• Paiement lié aux jalons
• Obligations de protection des données et de sécurité énoncées
• Conditions de maintenance et de résiliation claires
• Sous-traitance et continuité traitées
• Usage d'outils d'IA traité
• Relu par un avocat si le projet est significatif