Contrat agile / SCRUM : encadrer sans cahier des charges

Par David Joseph Atias, avocat au Barreau de Paris · LinkedIn · Juillet 2026

Le contrat agile répond à un paradoxe : comment encadrer juridiquement un projet dont le périmètre n’est pas figé d’avance ? La méthode agile, et notamment Scrum, a conquis le développement logiciel grâce à sa flexibilité. Mais cette flexibilité déstabilise les contrats classiques, bâtis sur un cahier des charges détaillé. Sans adaptation, le projet agile devient une zone de risque : périmètre flou, budget incontrôlé, propriété du code incertaine. Un contrat agile bien rédigé concilie adaptabilité et sécurité juridique. Cet article expose les modèles, le cadre juridique et les pièges à éviter pour encadrer un projet sans cahier des charges.

SOMMAIRE

1. Pourquoi le contrat agile est devenu stratégique en 2026
2. Le cadre juridique applicable
3. Les 7 clauses essentielles
4. Tableau de synthèse des modèles agiles
5. Les 5 pièges à éviter
6. Pourquoi faire appel à Atias Avocats
7. FAQ — Questions fréquentes

1. Pourquoi le contrat agile est devenu stratégique en 2026

Le contrat agile s’est imposé progressivement avec la généralisation des méthodes itératives dans le développement logiciel. La majorité des projets adoptent désormais une approche agile. Trois dynamiques renforcent son importance en 2026.

1.1 La domination des méthodes agiles

L’agilité est devenue la norme du développement. Selon plusieurs études sectorielles, la grande majorité des équipes techniques utilisent désormais Scrum ou une méthode apparentée. Le cahier des charges figé a cédé la place au product backlog évolutif. Pourtant, les contrats n’ont pas toujours suivi. Beaucoup de projets agiles tournent sous un contrat au forfait inadapté, source de tensions permanentes. Ce type de contrat comble ce décalage.

1.2 Le risque juridique de l’imprécision

L’absence de cahier des charges figé crée un risque juridique réel. Sans cadre adapté, le périmètre devient flou, le prix incertain, et la responsabilité difficile à établir. En cas d’échec, le client et le prestataire s’opposent sur ce qui était dû. Un cadre adapté transforme cette zone grise en cadre maîtrisé, en organisant la flexibilité plutôt qu’en la subissant. C’est un enjeu de sécurité pour les deux parties.

1.3 L’agilité appliquée aux projets d’IA

En 2026, les projets d’intelligence artificielle adoptent massivement l’agilité, car ils sont par nature exploratoires. Entraîner un modèle, tester des hypothèses, ajuster : ces démarches itératives appellent un cadre contractuel agile. Mais elles soulèvent aussi des questions de conformité au Règlement UE 2024/1689 (AI Act) et de propriété des modèles produits. Le contrat doit articuler agilité et conformité. Pour aller plus loin, consultez nos services en matière de contrats commerciaux et IT.

2. Le cadre juridique applicable

Le contrat agile mobilise avant tout le droit commun des contrats, adapté à un périmètre évolutif. Quatre fondements principaux structurent sa validité et son équilibre.

2.1 La détermination de l’objet (article 1163)

L’article 1163 du Code civil exige que l’obligation porte sur une prestation déterminée ou déterminable. C’est le cœur du défi agile. Ce contrat ne fige pas le périmètre, mais le rend déterminable par un mécanisme : product backlog priorisé, sprints, validation continue. Tant que ce mécanisme est clair, l’exigence légale est satisfaite. Un accord sans aucun cadre de détermination serait, en revanche, juridiquement fragile.

2.2 La fixation du prix (articles 1164 et 1165)

Le prix doit lui aussi être encadré. Dans un contrat-cadre, l’article 1164 du Code civil permet une fixation unilatérale assortie d’une justification. Pour les contrats de prestation de service, l’article 1165 autorise la fixation du prix par le créancier, à charge de le justifier en cas d’abus. Le contrat encadre généralement le prix par une enveloppe budgétaire, un coût par sprint ou un tarif d’équipe dédiée, ce qui sécurise la prévisibilité financière.

2.3 La propriété intellectuelle (CPI L.113-9 et L.131-3)

L’article L.113-9 du Code de la propriété intellectuelle attribue par défaut les droits sur le logiciel au prestataire. Pour que le client soit propriétaire, une cession conforme à l’article L.131-3 est nécessaire : mention écrite et précise de chaque droit cédé, du périmètre, de la durée et du territoire. La spécificité agile impose une cession incrémentale, sprint après sprint, pour que chaque livraison appartienne au client. Pour aller plus loin, consultez nos services en matière de protection des données personnelles.

2.4 Le risque de prêt de main-d’œuvre illicite

Comme la régie, ce mode comporte un risque de requalification. Si le client dirige directement l’équipe du prestataire, la relation peut être qualifiée de prêt de main-d’œuvre illicite (article L.8241-1 du Code du travail) ou de marchandage (article L.8231-1). Or, l’agilité implique une collaboration étroite et un product owner côté client. Le contrat doit donc préserver le lien de subordination entre le prestataire et ses salariés, malgré cette proximité opérationnelle.

3. Les 7 clauses essentielles

Un contrat agile bien construit s’articule autour de sept clauses essentielles. Chacune encadre une dimension du projet itératif et concilie flexibilité et sécurité.

3.1 Le cadre de collaboration et la gouvernance

La première clause définit le cadre. Elle décrit la méthode retenue (Scrum, Kanban), les rôles (product owner côté client, Scrum master, équipe de développement), les rituels (sprint planning, revue, rétrospective), et les instances de pilotage. Cette gouvernance remplace le cahier des charges figé par un mécanisme de décision continu. Elle en est le socle : sans gouvernance claire, la flexibilité dégénère en désordre.

3.2 Le product backlog et la priorisation

La deuxième clause encadre le product backlog (liste priorisée des fonctionnalités à développer). Elle précise qui le tient (le product owner), comment il évolue, et comment les priorités sont arbitrées. Le backlog est l’instrument qui rend l’objet déterminable au sens de l’article 1163 du Code civil. Le contrat doit garantir sa tenue rigoureuse, car il matérialise le périmètre en construction et tracera, en cas de litige, ce qui a été demandé et livré.

3.3 Les sprints et la vélocité

La troisième clause organise les sprints (itérations de durée fixe, souvent deux à quatre semaines). Elle définit leur durée, leur contenu, et la notion de vélocité (capacité de production de l’équipe par sprint). La vélocité permet d’estimer l’avancement et le budget. Le contrat doit prévoir un suivi transparent de la vélocité, car elle est l’indicateur clé du pilotage et un élément de preuve en cas de désaccord sur la productivité.

3.4 Le prix et le pilotage budgétaire

La quatrième clause fixe le modèle économique. Plusieurs options : régie agile (facturation au sprint), forfait par sprint (prix fixe par itération), capacité dédiée (équipe réservée à un tarif convenu), ou budget enveloppe avec arbitrage du périmètre. La clause doit prévoir le suivi budgétaire, les seuils d’alerte et les modalités d’ajustement. L’objectif est de concilier la flexibilité agile avec la prévisibilité financière exigée par le client.

3.5 La recette continue et les critères d’acceptation

La cinquième clause organise la recette continue. À chaque sprint, le client valide les fonctionnalités livrées selon des critères d’acceptation (definition of done) définis pour chaque élément du backlog. Cette validation incrémentale remplace la recette finale unique. Le contrat doit préciser la procédure de validation, le traitement des anomalies et les conséquences d’un refus. Une recette de clôture peut compléter le dispositif en fin de projet.

3.6 La propriété intellectuelle incrémentale

La sixième clause organise la cession des droits. Par défaut, l’article L.113-9 du Code de la propriété intellectuelle attribue les droits au prestataire. Le contrat doit prévoir une cession conforme à l’article L.131-3, transférant au client la propriété de chaque incrément à la validation du sprint correspondant. Cette cession au fil de l’eau garantit que le client est propriétaire du code livré, même si le projet s’arrête en cours de route. Les composants tiers et open source doivent être traités à part.

3.7 La sortie et la réversibilité à tout moment

La septième clause organise la sortie. L’agilité permet d’arrêter le projet à la fin de n’importe quel sprint. Le contrat doit donc prévoir une faculté de résiliation à échéance de sprint, avec préavis raisonnable, et organiser la réversibilité : restitution du code et de la documentation produits, transfert de compétences, propriété des incréments déjà livrés. Cette flexibilité de sortie est un avantage majeur de l’agile, à condition d’être contractualisée.

4. Tableau de synthèse des modèles agiles

Le tableau ci-dessous compare les principaux modèles économiques agiles selon la répartition du risque et le niveau de flexibilité.

5. Les 5 pièges à éviter

Au-delà des clauses, plusieurs pièges récurrents fragilisent les projets agiles. Les identifier permet d’éviter les litiges les plus fréquents.

5.1 Plaquer un contrat au forfait classique sur un projet agile

Le premier piège est le contrat inadapté. Beaucoup de projets agiles tournent sous un contrat au forfait classique, avec cahier des charges figé. La méthode contredit alors le contrat : l’équipe travaille en sprints, mais le contrat exige un périmètre fixe. Résultat : avenants permanents, tensions, contentieux. Le contrat doit épouser la méthode réellement employée, pas l’inverse. C’est une erreur de cohérence très répandue.

5.2 Laisser le périmètre totalement indéterminé

Le deuxième piège est l’excès inverse : l’absence totale de cadre. Un contrat agile n’est pas un blanc-seing. L’article 1163 du Code civil exige un objet déterminable. Sans backlog initial, sans objectifs généraux, sans mécanisme de priorisation, le contrat est juridiquement fragile et opérationnellement ingérable. La flexibilité agile doit être encadrée par une gouvernance claire. Encadrer n’est pas figer : c’est rendre le périmètre maîtrisable.

5.3 Oublier la cession incrémentale des droits

Le troisième piège concerne la propriété. Dans un projet agile, le code est produit sprint après sprint. Si la cession des droits n’est prévue qu’à la fin, un arrêt en cours de projet laisse le client sans propriété sur les incréments déjà payés. La clause de cession doit donc transférer les droits au fil de l’eau, à chaque validation de sprint, conformément à l’article L.131-3 du Code de la propriété intellectuelle. Cette précaution est essentielle dans un cadre itératif.

5.4 Diriger directement l’équipe du prestataire

Le quatrième piège est lié à la proximité agile. La collaboration étroite, avec un product owner côté client, peut glisser vers une direction directe des développeurs. La relation risque alors la requalification en prêt de main-d’œuvre illicite (article L.8241-1 du Code du travail). Le contrat doit organiser le pilotage par le backlog et les rituels Scrum, sans subordination directe, en préservant le lien hiérarchique entre le prestataire et son équipe.

5.5 Négliger la recette et la traçabilité

Le cinquième piège est l’absence de traçabilité. En agile, la rapidité peut faire négliger la documentation des validations. Or, en cas de litige, il faut prouver ce qui a été demandé, livré et accepté. Le contrat doit imposer une traçabilité rigoureuse : backlog historisé, critères d’acceptation, comptes rendus de revue de sprint, validations formalisées. Cette discipline documentaire est la meilleure protection en cas de désaccord sur le périmètre ou la conformité.

6. Pourquoi faire appel à Atias Avocats

Rédiger un tel contrat à la hauteur des enjeux exige une combinaison rare de compétences : maîtrise du droit des contrats (articles 1163, 1164, 1165, 1170 du Code civil), expertise de la propriété intellectuelle (CPI L.113-9, L.131-3), connaissance du droit du travail (risque de prêt de main-d’œuvre illicite), et surtout une compréhension fine des méthodes agiles (Scrum, Kanban, backlog, sprints, vélocité, definition of done). Cette double culture juridique et technique est précisément la valeur ajoutée d’un cabinet spécialisé en contrats IT et droit du numérique.

Atias Avocats accompagne éditeurs, ESN (entreprises de services du numérique), startups, scale-ups, donneurs d’ordre et prestataires sur l’ensemble du sujet : rédaction de contrats agiles (régie agile, forfait par sprint, capacité dédiée), structuration de la cession incrémentale des droits, sécurisation contre la requalification, articulation avec le RGPD et l’AI Act, audit d’un contrat existant, défense en cas de litige (projet agile en échec, désaccord sur le périmètre, contestation de propriété). Pour aller plus loin, consultez nos services en matière de contrats commerciaux et IT.

Conclusion

Le contrat agile résout, on le voit, un paradoxe apparent : sécuriser juridiquement la flexibilité. La clé n’est pas de figer le périmètre, mais de rendre l’objet déterminable par un mécanisme clair — backlog, sprints, recette continue, cession incrémentale. Les sept clauses présentées ici, combinées à la vigilance sur les cinq pièges classiques, offrent un référentiel directement utilisable par CTO, directions des systèmes d’information, product owners et directions juridiques. Le contrat épouse alors la méthode, au lieu de la contredire.

L’investissement requis pour rédiger ou négocier sérieusement ce contrat est sans commune mesure avec le coût d’un projet agile en échec ou d’un litige sur le périmètre. Pour un projet innovant ou exploratoire, c’est l’assurance d’une collaboration fluide, d’une propriété maîtrisée et d’une sortie possible à tout moment. Le réflexe à adopter est clair : aligner le contrat sur la méthode, encadrer la gouvernance, organiser la recette continue, céder les droits au fil de l’eau, sécuriser la sortie. C’est précisément cette rigueur qui transforme l’agilité en avantage maîtrisé plutôt qu’en zone de risque.

FAQ — Questions fréquentes

Peut-on signer un contrat sans cahier des charges figé ?

Oui, c’est précisément l’objet du contrat agile. La méthode agile repose sur un périmètre évolutif, défini progressivement au fil des itérations (sprints). Le contrat ne fige donc pas un cahier des charges détaillé en amont, mais encadre un cadre de collaboration : objectifs généraux, product backlog (liste priorisée des fonctionnalités), durée des sprints, rôles, modalités de pilotage. Juridiquement, l’article 1163 du Code civil exige que l’objet de l’obligation soit déterminé ou déterminable. Le contrat agile satisfait cette exigence en rendant l’objet déterminable par le mécanisme contractuel (backlog, sprints, validation continue). Le défi est d’encadrer la flexibilité sans tomber dans l’imprécision : c’est tout l’art de la rédaction d’un accord équilibré, qui protège le client comme le prestataire.

Forfait, régie ou contrat agile : quelle différence ?

Le forfait fige un prix et un périmètre : il convient aux projets bien cadrés, mais s’adapte mal au changement. La régie facture le temps passé : flexible, mais le client porte le risque budgétaire. C’est une troisième voie, souvent hybride. Il combine un cadre global (budget enveloppe ou capacité d’équipe) avec une flexibilité du périmètre par sprint. Plusieurs modèles existent : la régie agile (facturation au sprint avec backlog évolutif), le forfait par sprint (prix fixe par itération à périmètre variable), ou le contrat à capacité dédiée (équipe réservée). Ce modèle cherche à concilier maîtrise budgétaire et adaptabilité, là où le forfait pur et la régie pure échouent sur les projets innovants ou exploratoires.

Comment gérer la recette dans un projet agile ?

La recette agile est continue, et non globale comme au forfait classique. À la fin de chaque sprint, le client valide les fonctionnalités livrées lors d’une revue de sprint (sprint review), sur la base de critères d’acceptation définis pour chaque élément du backlog (definition of done). Cette validation incrémentale remplace la recette finale unique. Le contrat doit organiser cette recette continue : critères d’acceptation par fonctionnalité, procédure de validation à chaque sprint, traitement des anomalies, conséquences d’un refus. Une recette de clôture peut compléter le dispositif à la fin du projet. L’avantage est majeur : les écarts sont détectés tôt, sprint après sprint, ce qui réduit considérablement le risque de litige final sur la conformité du livrable.

À qui appartient le code produit en méthode agile ?

Comme pour tout développement, l’article L.113-9 du Code de la propriété intellectuelle attribue par défaut les droits sur le logiciel au prestataire, sauf cession expresse. Le contrat doit donc organiser la cession des droits au profit du client, conformément à l’article L.131-3 du Code de la propriété intellectuelle, qui impose la mention écrite et précise de chaque droit cédé. La particularité agile est que le code est produit de façon incrémentale, sprint après sprint. La clause de cession doit donc prévoir un transfert au fil de l’eau, idéalement à la validation de chaque sprint, pour que le client soit propriétaire de chaque incrément livré. Il faut aussi traiter les composants préexistants et open source. Une cession bien rédigée évite que le client se retrouve dépendant à la fin du projet.

Contact : david@atiasavocats.com | LinkedIn: David Joseph Atias | https://www.atiasavocats.com | 42 rue de la Clef, 75005 Paris

Atias Avocats — Contrats IT, Développement agile, Propriété intellectuelle, AI Act