Le développement logiciel agile s'accorde mal avec les contrats où le résultat final, le périmètre du projet et la date de livraison sont fixés à l'avance. Dans un projet agile, les parties travaillent par sprints courts, périodes de travail définies, et le contenu du produit est ajusté au fur et à mesure de l'avancement du projet.
Cela offre de la flexibilité, mais soulève également des questions juridiques. Qui fixe les priorités ? Quand le résultat d’un sprint est-il accepté ? Et quand un retard de livraison entraîne-t-il un manquement ? Cet article explique comment les parties peuvent répondre à ces questions par voie contractuelle.
Par contrat agile, nous entendons, dans la suite de ce texte, l'ensemble des modalités par lesquelles les parties formalisent une collaboration agile. Concrètement, cette collaboration prend la forme d'un accord-cadre assorti d'accords d'exécution distincts pour chaque mission.
Travail agile et contractualisation
Dans un projet informatique traditionnel, les parties définissent au préalable une conception fonctionnelle et technique. Le fournisseur s'engage ensuite à livrer ce résultat à une date donnée. En développement agile, cette destination fixe est délibérément absente : le résultat est un objectif évolutif.
Chaque sprint livre une partie fonctionnelle et utilisable du logiciel. Le client ajuste ensuite le projet en fonction des démonstrations et des retours utilisateurs. Contrairement à un contrat traditionnel qui fixe la fin du projet, la méthodologie agile permet une plus grande flexibilité.
Les parties doivent donc convenir contractuellement de ce qu'un projet traditionnel fait généralement déjà ressortir du cahier des charges. Quatre points se distinguent :
- qui détermine les spécifications, c'est-à-dire qui remplit le rôle de propriétaire du produit (la personne qui fixe les priorités au nom du client) ;
- comment les modifications sont intégrées au backlog (la liste priorisée des fonctionnalités restant à développer), la planification et le prix ;
- lorsqu'un composant est considéré comme terminé, sur la base d'une définition de « terminé » (les critères convenus pour un résultat final) et de critères d'acceptation (les exigences par rapport auxquelles une livraison est testée) ;
- que les dates de livraison convenues soient strictes ou indicatives.
Une conséquence pratique : le travail agile est difficilement compatible avec un appel d’offres dont le périmètre est entièrement défini à l’avance. Une partie soumise aux règles des marchés publics qui souhaite néanmoins un développement agile a tout intérêt à prévoir, dans le cahier des charges, un accord-cadre assorti de missions de mise en œuvre flexibles.
Obligation de faire de son mieux ou obligation de résultats ?
Dans le cadre d'une obligation de moyens, le fournisseur ne garantit pas de résultat particulier. Il s'engage à apporter le soin qu'on attend d'un professionnel raisonnablement compétent et agissant de manière raisonnable. Dans le cadre d'une obligation de résultat, il s'engage à atteindre un résultat spécifiquement décrit.
La formulation du contrat n'est pas déterminante. Même lorsqu'un contrat fait référence à une obligation de résultat, le tribunal peut conclure, au vu du contenu des accords et de leur contexte, qu'il s'agit en réalité d'une obligation de moyens, et inversement. La manière dont les parties collaborent concrètement est donc au moins aussi importante que le choix des termes.
Cette distinction est importante en pratique car, dans le cadre d'une obligation de résultat, le résultat convenu est primordial, tandis que dans le cadre d'une obligation de moyens, il convient d'évaluer si le fournisseur a déployé les efforts requis. Cette différence détermine l'objet du litige et les éléments que les parties doivent prouver.
Deux dispositions légales s'appliquent ici. L'article 6:74(1) du Code civil néerlandais prévoit les conditions d'octroi de dommages-intérêts en cas d'inexécution imputable à un tiers. Il ne précise cependant pas les conditions d'existence de cette inexécution ; celle-ci dépend de la qualification de l'obligation et du contenu des accords. L'article 6:248 dispose qu'un contrat produit également les effets découlant du principe de raisonnabilité et d'équité. Cela permet de prendre en compte la nature agile de la collaboration lors de l'interprétation des obligations des parties.
Base contractuelle : accords-cadres et accords de mise en œuvre
En pratique, la collaboration agile s'organise en couches. Un accord-cadre définit le cadre général : conditions applicables, responsabilité, confidentialité et modalités de coopération.
Pour chaque mission, les parties concluent un accord de mise en œuvre précisant le périmètre, la planification, la composition de l'équipe, le prix et les critères d'acceptation. La relation juridique demeure ainsi stable tandis que le contenu peut évoluer à chaque sprint ou version.
Sans critères d'acceptation clairs, il n'existe aucune trace de ce à quoi le résultat doit être comparé. Les litiges quant à la réussite du sprint s'en trouvent alors plus fréquents. Des critères d'acceptation concrets et mesurables pour chaque sprint sont donc plus importants que la qualification donnée par les parties à l'obligation.
Dans les contrats agiles, la résiliation anticipée mérite une attention particulière par rapport aux contrats informatiques traditionnels. Un projet agile étant constitué d'une succession de sprints sans date de fin fixe, le contrat doit définir les conditions d'arrêt, le sort des composants et du code source déjà livrés, ainsi que les modalités de transfert vers un autre prestataire.
Les conditions générales sont également importantes. Les Conditions générales NLdigital 2025 remplacent l'édition 2020 et intègrent des chapitres sur la conformité, la cybersécurité, le partage de données, l'intelligence artificielle et les plateformes en ligne, entre autres. Les conditions de 2020 restent applicables là où les parties les ont convenues ; vérifiez donc quelle version s'applique à votre contrat. Elles n'abordent que partiellement les aspects spécifiques à l'agilité ; ces derniers doivent être définis par les parties dans l'accord de mise en œuvre.
Jurisprudence relative aux délais et à la coopération
La jurisprudence ne fait état d'aucune règle générale interdisant de respecter un délai de livraison strict dans le cadre d'une méthode agile. Ce respect dépend du contenu du contrat, de la méthode de travail choisie et de la coopération effective des parties. Trois cas illustrent ce point.
Tribunal de district de Midden-Nederland, 26 juillet 2023 (ECLI:NL:RBMNE:2023:5936). Le fournisseur IPS a développé un logiciel de pesage pour le client Synergy, en utilisant la méthode Scrum. Le contrat prévoyait un délai de livraison d'environ 24 semaines. Ce délai n'ayant pas été respecté, une nouvelle échéance a été reportée, puis de nouveau manquée. Mi-décembre 2020, alors que neuf des dix modules hebdomadaires convenus avaient été livrés, Synergy a résilié le contrat. Le tribunal a jugé que le délai promis constituait une échéance stricte, et qu'il y avait donc eu manquement. La résiliation a cependant été jugée non valable : compte tenu de la nature de la collaboration, qui prévoit la mise en place de nouvelles dispositions en cas de non-respect des délais, et du fait que le projet était presque achevé, ce manquement ne justifiait pas la résiliation. Conséquence pratique : même dans le cadre d'une collaboration agile, un délai promis peut être strict, mais un manquement n'entraîne pas automatiquement la validité d'une résiliation.
Tribunal de district Amsterdam22 avril 2026 (ECLI:NL:RBAMS:2026:3930). Un client a allégué que le développeur DTT avait livré une nouvelle application mobile en retard, dépassé le budget et assuré une maintenance insuffisante des applications existantes. Le tribunal a débouté le client de toutes les demandes. Aucun délai strict n'avait été fixé : la date de livraison mentionnée dans le devis et la correspondance devait être interprétée comme une obligation de fournir les meilleurs efforts possibles dans le cadre d'une méthode de travail agile ou Scrum, où la flexibilité et l'adaptation constante sont essentielles. Conséquence pratique : la partie qui souhaite qu'une date soit impérative doit le préciser expressément ; une date figurant dans un devis ne suffit pas.
Amsterdam Dans l'affaire opposant On Air à Triple IT, la Cour d'appel a statué que les parties avaient convenu de travailler selon la méthode agile ou Scrum sans définir de résultats finaux. Dans ce contexte, l'obligation se limite à mettre à disposition des développeurs compétents qui s'appliquent conformément au cahier des charges et avec le devoir de diligence d'un entrepreneur consciencieux. Si le produit livré n'est pas conforme, les efforts déployés pour le rendre conforme constituent en principe un travail supplémentaire. La situation peut être différente si le fournisseur n'a pas respecté les accords ou son devoir de diligence, mais la charge de la preuve incombe alors au client. Le simple fait que les performances du produit final ne répondent pas aux attentes du client est donc insuffisant pour établir un manquement. Dans cette affaire, la Cour a également désigné un expert informatique pour expliquer des termes tels que « scrum master », « sprint » et « terminé ». Conséquence pratique : en l'absence de résultats finaux définis, les travaux correctifs sont généralement à la charge du client.
Pour examiner une demande de résolution, le tribunal peut donc prendre en compte le rôle de chaque partie dans le retard et le déroulement du projet. La partie qui ne souhaite pas se fier à cette appréciation dans un cas particulier doit consigner par écrit les dates limites impératives et les cas où une résiliation anticipée est possible.
Huit points à aborder dans le contrat
Lors de la rédaction d'un contrat agile, tenez compte des points suivants. Pour chaque point, formulez la réponse à la question correspondante.
- Périmètre : quelles fonctionnalités relèvent du sprint et lesquelles en sont expressément exclues ?
- Priorisation : qui peut modifier le carnet de commandes, et cette personne a-t-elle le mandat de le faire au nom du client ?
- Acceptation : dans quel délai le client doit-il tester et répondre, et que se passe-t-il s’il ne le fait pas ?
- Délais : la date indiquée est-elle indicative ou impérative, et le contrat le précise-t-il clairement ?
- Prix : le paiement se fait-il par sprint, par point de fonction, par heure déployée ou par résultat ?
- Propriété et utilisation : à quel moment le client obtient-il l’accès au code source et à la documentation ?
- Résiliation : quels sont les droits transférés en cas de résiliation anticipée, et en contrepartie de quel paiement ?
- Continuité : un autre fournisseur peut-il poursuivre le travail, et quelles sont les exigences en matière de documentation et de transférabilité du code ?
Incluez également une définition de « terminé » qui soit non seulement fonctionnelle, mais qui définisse aussi les exigences en matière de qualité, de documentation et de transférabilité du code. À défaut, un litige concernant l'utilisabilité du travail livré risque de survenir à la fin du contrat.
Conclusion
Le travail agile offre de la flexibilité, mais exige un contrat fondamentalement différent du modèle traditionnel. La distinction entre l'obligation de fournir les meilleurs efforts et l'obligation d'obtenir des résultats, des critères d'acceptation clairs et une clause de résiliation anticipée sont déterminants. Les cas étudiés montrent que le résultat dépend fortement des modalités spécifiques et de la coopération effective. Un contrat prenant en compte ces points correspond mieux aux pratiques réelles des parties et réduit les risques de litiges.
Law & More Nous accompagnons les fournisseurs et clients informatiques dans la rédaction, la révision et la négociation d'accords-cadres et de contrats de mise en œuvre, et nous les conseillons sur la qualification des obligations, les critères d'acceptation et les modalités de sortie. Vous rencontrez un litige concernant un retard, des résultats ou l'arrêt d'un projet agile ? N'hésitez pas à nous contacter pour obtenir des conseils personnalisés.
Foire aux questions
Vous trouverez ci-dessous les réponses aux questions qui nous sont le plus souvent posées à ce sujet.
Qu'est-ce qu'un contrat agile ?
L'ensemble des modalités permettant aux parties de formaliser une collaboration agile. En pratique, il se compose d'un accord-cadre définissant le cadre général, et d'un accord d'exécution pour chaque mission précisant le périmètre, la planification, le prix et les critères d'acceptation de cette mission.
Dans un projet agile, une date de livraison est-elle une échéance stricte ?
Pas automatiquement. Il n'y a pas de règle générale ; cela dépend du contrat, de la méthode de travail et de la collaboration effective. Si vous souhaitez une date précise, indiquez-le clairement. Une date figurant dans un devis est insuffisante.
Quelle est la différence entre une obligation de faire de son mieux et une obligation de résultats ?
Dans le cadre d'une obligation de résultats, le résultat convenu est primordial. Dans le cadre d'une obligation de moyens, il convient d'évaluer si le fournisseur a déployé les efforts requis. Cette différence détermine l'objet du litige entre les parties.
L'étiquette figurant dans le contrat est-elle déterminante ?
Non. Même si le contrat mentionne une obligation de résultat, le tribunal peut, au vu du fond et du contexte, conclure qu'il s'agit en réalité d'une obligation de moyens, et inversement. Les modalités de travail effectives des parties sont tout aussi importantes.
Qui peut modifier le carnet de commandes ?
La personne assumant le rôle de responsable produit. Il est important de noter son identité et de préciser si elle est mandatée pour agir au nom du client. Sans cette précision, des conflits peuvent survenir quant à la responsabilité des changements de priorités.
Pourquoi les critères d'acceptation sont-ils si importants ?
Sans critères d'acceptation clairs, il n'existe aucune trace de ce à quoi le résultat doit être comparé. Les désaccords quant à la réussite du sprint surgissent alors plus facilement. En pratique, ils ont plus d'importance que l'étiquette apposée à l'obligation.
Qui prend en charge les frais de réparation si la livraison n'est pas conforme ?
En l'absence de résultats définitifs définis, les efforts déployés pour satisfaire les souhaits du client sont en principe à sa charge et constituent un travail supplémentaire. La situation est différente lorsque le fournisseur n'a pas respecté les accords ou son obligation de diligence, mais la charge de la preuve incombe alors au client.
Comment le paiement est-il organisé dans le cadre du travail agile ?
Lier le paiement à une date de livraison fixe est incompatible avec une méthode sans résultat final prédéfini. Les alternatives courantes sont le paiement par sprint, par point de fonction ou par heure travaillée. Il est important de consigner explicitement la base de paiement choisie.
Est-il possible de combiner le travail agile avec un appel d'offres public ?
Cela exige une approche adaptée, car un appel d'offres au périmètre entièrement défini présuppose un résultat connu d'avance. Il convient de prévoir dans le cahier des charges un accord-cadre assorti de modalités de mise en œuvre flexibles.
Que dois-je prévoir concernant une rupture anticipée du contrat ?
À quelles conditions une partie peut-elle interrompre le travail, qu'advient-il des composants et du code source déjà livrés, en contrepartie de quel transfert de paiement est effectué, et de quoi un autre fournisseur a-t-il besoin pour poursuivre les travaux ?
Les conditions générales de NLdigital 2025 fournissent-elles des indications suffisantes ?
Seulement dans une certaine mesure. Ces documents succèdent à l'édition 2020 et ajoutent des chapitres sur la conformité, la cybersécurité, le partage de données, l'intelligence artificielle et les plateformes en ligne, entre autres, mais n'abordent pas les aspects spécifiques de la méthodologie agile. Les conditions de l'édition 2020 restent applicables là où elles ont été convenues. Vous devrez définir vous-même ces aspects dans l'accord de mise en œuvre.
Vous avez un litige avec un fournisseur informatique ou vous souhaitez faire réviser un contrat informatique ? Nos avocats spécialisés en droit des technologies de l’information sont là pour vous aider.
Comment Law & More Nous pouvons vous aider. Tout est expliqué sur notre site web. avocat en technologies de l'information .
