Exemple de rédaction commenté
L’exemple ci-dessous vise un projet informatique au forfait, mais il se transpose à toute prestation dont le périmètre est défini à l’avance. Chaque délai et chaque plafond doivent être calés sur le rythme réel du projet et sur la capacité des parties à instruire les demandes.
Article X. Gestion des évolutions (change request)
X.1. Le périmètre des prestations est défini par le Cahier des charges et ses annexes. Toute prestation qui excède ce périmètre, le modifie ou en change les hypothèses constitue une Évolution. Aucune Évolution n’est due ni facturable tant qu’elle n’a pas été validée selon la procédure du présent article. Le Prestataire n’est pas tenu d’exécuter une Évolution non validée, et le Client n’est pas tenu de la payer.
X.2. Chaque Partie peut adresser à l’autre une Demande d’évolution écrite décrivant le besoin, son origine et le résultat attendu. La Demande est transmise au [chef de projet] de l’autre Partie et enregistrée dans le [registre des évolutions] tenu par le Prestataire.
X.3. Dans un délai de [dix] jours ouvrés à compter de la réception d’une Demande, le Prestataire remet un Devis d’évolution précisant les travaux, leur coût selon [le taux journalier convenu en Annexe], l’incidence sur le calendrier, les livrables affectés et la durée de validité du Devis. Si l’instruction de la Demande représente elle-même une charge significative, le Prestataire en informe le Client avant de l’engager.
X.4. L’Évolution n’est validée que par un accord écrit des deux Parties prenant la forme d’un [avenant] ou d’un [bon de commande signé] renvoyant au Devis. Le silence du Client ne vaut pas acceptation. Aucun travail relatif à une Évolution n’est engagé avant cette validation.
X.5. L’Évolution validée modifie le Contrat dans la seule mesure qu’elle définit. Elle actualise en conséquence le périmètre, le prix et le calendrier, y compris le report des jalons dont l’Évolution retarde l’exécution. À défaut de stipulation contraire dans l’accord de validation, les autres clauses du Contrat demeurent inchangées.
X.6. À défaut d’accord sur une Demande, le périmètre initial se poursuit sans modification et le désaccord est soumis à la procédure de [gouvernance de projet] prévue à l’article [.]. Le refus d’une Demande n’ouvre par lui-même aucun droit à indemnité au profit de la Partie qui l’a formulée.
Commentaire de X.1 : la frontière du périmètre décide de tout. Sans définition claire de ce qui est inclus, la notion d’Évolution n’a pas de sens : le client dira que tout était compris, le prestataire que rien ne l’était. Le renvoi au cahier des charges est donc le socle de la clause. Poser que rien n’est dû ni facturable hors procédure protège les deux parties : le prestataire contre les demandes gratuites, le client contre les factures surprises.
Commentaire de X.2 et X.3 : formaliser la demande et le chiffrage. Une demande écrite, adressée à un interlocuteur identifié et tracée dans un registre, évite les malentendus sur ce qui a été demandé et quand. Le devis doit chiffrer les deux dimensions, le prix et le délai : une évolution modeste en coût peut décaler un jalon critique. Prévoir que l’instruction d’une demande lourde soit signalée avant d’être engagée évite qu’un simple chiffrage devienne une prestation non prévue.
Commentaire de X.4 : la validation écrite est le verrou. C’est ici que se forme l’accord au sens de l’article 1193 du Code civil. Stipuler que le silence ne vaut pas acceptation et interdire tout démarrage avant validation protège chacun : le prestataire ne travaille pas sans commande, le client ne se voit pas opposer un accord tacite. La forme retenue, avenant ou bon de commande, doit être cohérente avec la clause de hiérarchie des documents contractuels.
Commentaire de X.5 : mesurer précisément l’effet sur le contrat. Une évolution ne doit modifier que ce qu’elle vise. Préciser qu’elle actualise le prix, le périmètre et le calendrier, jalons compris, évite qu’un client obtienne l’ajout sans accepter le report, ou qu’un prestataire facture l’ajout sans réviser les délais. Le lien avec les délais d’exécution doit être explicite, faute de quoi une pénalité de retard pourrait sanctionner un décalage causé par une évolution acceptée.
Commentaire de X.6 : organiser le désaccord. Une demande peut être refusée : la clause doit dire ce qui se passe alors. Poser que le périmètre initial se poursuit et renvoyer à une gouvernance de projet évite le blocage. Préciser que le refus n’ouvre pas de droit à indemnité coupe court à l’idée qu’une partie pourrait réclamer réparation d’une évolution qu’elle a seulement proposée.
Ce que dit le droit
La clause de change request est une clause largement innommée : aucun texte spécial ne lui est consacré. Son régime relève du droit commun des contrats, en particulier des règles sur la modification du contrat, sur la détermination du prix et sur la bonne foi.
Une évolution est une modification du contrat, qui suppose un accord mutuel. L’article 1193 du Code civil énonce que les contrats ne peuvent être modifiés ou révoqués que du consentement mutuel des parties, ou pour les causes que la loi autorise. Une évolution du périmètre modifie l’objet des prestations : elle ne s’impose donc à personne tant que les deux parties ne l’ont pas acceptée. C’est ce qui justifie la procédure de demande, de chiffrage et de validation : elle est la mise en forme concrète de l’accord exigé par ce texte.
La liberté contractuelle permet d’organiser cette procédure. L’article 1102 du Code civil laisse aux parties la liberté de déterminer le contenu du contrat dans les limites fixées par la loi, et l’article 1103 énonce que les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits. Les délais de réponse, la forme de la validation ou l’interdiction de démarrer sans accord, une fois stipulés, s’imposent aux parties. La clause tire ainsi sa force de sa rédaction, non d’un régime légal préexistant.
La bonne foi encadre le jeu des demandes et des refus. L’article 1104 du Code civil impose que les contrats soient négociés, formés et exécutés de bonne foi, et précise que cette disposition est d’ordre public. Un prestataire ne peut pas retarder abusivement le chiffrage d’une évolution nécessaire, ni un client multiplier des demandes dans le seul but de désorganiser le projet ou refuser sans motif une évolution indispensable qu’il a lui-même rendue nécessaire. La bonne foi n’oblige pas à accepter une évolution, mais interdit d’instrumentaliser la procédure.
Le prix d’une évolution obéit aux règles de détermination du prix. L’article 1163 du Code civil exige que la prestation soit déterminée ou déterminable sans qu’un nouvel accord soit nécessaire. Faute de prix convenu à l’avance, deux mécanismes de droit commun s’appliquent selon la nature du contrat : dans un contrat de prestation de service, l’article 1165 du Code civil autorise le créancier à fixer le prix à défaut d’accord préalable, à charge d’en motiver le montant en cas de contestation, l’abus ouvrant droit à des dommages et intérêts et, le cas échéant, à la résolution ; dans un contrat cadre, l’article 1164 du Code civil admet une fixation unilatérale par une partie, soumise au même contrôle de l’abus. Prévoir un taux journalier ou une grille dans le contrat, puis un devis validé pour chaque évolution, sécurise ce point mieux qu’une fixation unilatérale exposée à contestation. La clause de révision de prix règle une autre question, l’évolution du prix des prestations déjà convenues, à ne pas confondre avec le chiffrage d’un périmètre nouveau.
Le forfait n’interdit pas de facturer les évolutions convenues. On invoque parfois le caractère forfaitaire d’un marché pour refuser toute facturation supplémentaire. En droit de la construction, l’article 1793 du Code civil interdit à l’entrepreneur ayant construit un bâtiment à forfait de réclamer un supplément pour des changements non autorisés par écrit par le maître de l’ouvrage : la logique est bien celle d’une autorisation écrite préalable. Ce texte vise spécifiquement le bâtiment et ne régit pas les prestations informatiques, mais il éclaire la mécanique retenue par la clause de change request : hors du périmètre forfaitisé, un supplément suppose un accord écrit. [À VÉRIFIER JURISTE : périmètre d’application de l’article 1793 du Code civil et impossibilité de le transposer à un forfait de prestation informatique.]
La responsabilité de droit commun demeure en arrière-plan. L’article 1231-1 du Code civil condamne le débiteur au paiement de dommages et intérêts en cas d’inexécution ou de retard, sauf force majeure. Une évolution mal articulée avec le calendrier peut ainsi faire naître une responsabilité pour retard si la clause ne prévoit pas le report des jalons. Par ailleurs, si le contrat assortit la procédure d’un forfait sanctionnant, par exemple, un chiffrage tardif, cette stipulation peut s’analyser en clause pénale soumise au pouvoir de révision du juge au titre de l’article 1231-5 du Code civil.
Les erreurs fréquentes
Laisser démarrer les travaux avant la validation écrite. C’est l’erreur la plus coûteuse. Tant que l’accord n’est pas formé, l’article 1193 du Code civil prive l’évolution de force obligatoire : le prestataire exécute sans base pour être payé, le client sans prix ni délai convenus. La clause doit interdire tout démarrage avant validation et écarter l’acceptation tacite.
Ne pas définir le périmètre initial. Sans cahier des charges précis, la notion d’évolution est vide : impossible de dire ce qui excède le périmètre puisque le périmètre n’est pas arrêté. Le change request suppose un point de référence stable. Faute de quoi chaque demande devient un débat sur ce qui était compris dès l’origine.
Chiffrer le prix sans traiter le délai. Une évolution acceptée décale souvent le calendrier. Si la clause n’organise pas le report des jalons, une pénalité de retard peut sanctionner un décalage pourtant causé par une évolution que le client a lui-même demandée. Le devis doit porter sur les deux dimensions, prix et délais.
Imposer un prix unilatéral non encadré. Fixer le tarif d’une évolution sans grille convenue ni motivation expose la clause au contrôle de l’abus prévu aux articles 1164 et 1165 du Code civil. Un taux journalier stipulé au contrat, puis un devis soumis à validation, valent mieux qu’un prix décidé seul et contestable.
Confondre change request, maintenance évolutive et imprévision. Le change request gère une demande volontaire d’évolution du périmètre projet. La maintenance corrective et évolutive couvre la vie d’une solution déjà livrée. L’imprévision de l’article 1195 du Code civil traite un bouleversement subi de l’économie du contrat. Employer l’une pour l’autre crée des angles morts.
Omettre la traçabilité des demandes. Des évolutions demandées par messagerie, sans registre ni référence, deviennent impossibles à reconstituer le jour du litige. Un registre daté, un interlocuteur identifié et une numérotation des demandes préparent la preuve de ce qui a été convenu, et de ce qui ne l’a pas été.
Négociation : ce que défend chaque partie
Ce que défend le prestataire ou l’éditeur. Il veut une frontière nette du périmètre initial, pour facturer tout ce qui la dépasse, un délai de réponse confortable pour instruire les demandes, un taux journalier protecteur et le report automatique des jalons affectés par une évolution. Son objectif est de ne jamais travailler gratuitement et de neutraliser le risque qu’un retard causé par une évolution lui soit imputé.
Ce que défend le client. Il veut un périmètre initial complet, pour que peu de choses en sortent, des délais de chiffrage courts, un prix des évolutions prévisible et encadré, et la garantie qu’une demande refusée ou tardivement chiffrée ne bloque pas le projet. Il redoute la sous-cotation initiale suivie d’évolutions facturées au prix fort, et veille à ce que la réception et la recette portent bien sur le périmètre réellement livré, évolutions comprises.
Où se situe l’équilibre. Le plus souvent sur trois arbitrages : la précision du périmètre de départ, le mode de fixation du prix des évolutions, et le sort du calendrier. Un point de convergence courant consiste à investir dans un cahier des charges détaillé pour réduire le volume d’évolutions, à fixer au contrat une grille tarifaire opposable plutôt qu’un prix décidé au coup par coup, et à prévoir un report de jalons proportionné à la charge réelle de chaque évolution validée. La clause se coordonne alors avec ses voisines : le cahier des charges pose le périmètre, la clause de délais d’exécution absorbe les décalages, la clause de révision de prix règle l’évolution du prix des prestations déjà convenues. Articulées, ces clauses évitent qu’une même évolution soit à la fois facturée, sanctionnée par une pénalité de retard et contestée sur son périmètre.
Les contrats qui contiennent cette clause
Modèles prêts à l'emploi dans lesquels cette clause figure.
- Modèle de CGV agence digitale gratuit (Word) à télécharger
- Modèle d'avenant à un contrat gratuit (Word)
- Modèle de contrat d'intégration informatique gratuit (Word)
- Modèle de contrat de développement logiciel au forfait (Word)
- Contrat de tierce maintenance applicative (TMA) gratuit (Word)
- Contrat de prestation de services pour agence web (Word)
- Contrat de prestation de services pour bureau d'études (Word)
- Contrat de prestation de services développeur freelance (Word)
Clauses voisines
Questions fréquentes
Une demande d'évolution formulée oralement engage-t-elle le prestataire ?
En principe non, si le contrat impose une procédure écrite. L'article 1193 du Code civil énonce que les contrats ne peuvent être modifiés que du consentement mutuel des parties. Une évolution du périmètre est une modification du contrat : elle suppose un accord, que la clause de change request organise sous forme de demande, de chiffrage puis de validation écrite. Une demande orale ne vaut ni commande ni acceptation d'un nouveau prix ou d'un nouveau délai.
Le prestataire peut-il fixer seul le prix d'une évolution supplémentaire ?
Seulement dans les limites du droit commun. Dans un contrat de prestation de service, l'article 1165 du Code civil autorise, à défaut d'accord préalable, une fixation du prix par le créancier, à charge d'en motiver le montant en cas de contestation, l'abus ouvrant droit à dommages et intérêts et, le cas échéant, à la résolution. Mieux vaut prévoir un chiffrage soumis à validation : la sécurité vient de l'accord, pas d'un prix imposé.
Quelle différence entre un change request et l'imprévision de l'article 1195 ?
Le change request est un mécanisme volontaire : une partie demande une évolution du périmètre, l'autre la chiffre, les deux la valident. L'imprévision de l'article 1195 du Code civil est un remède légal à un changement de circonstances imprévisible rendant l'exécution excessivement onéreuse, ouvrant une renégociation puis, à défaut d'accord, la révision du contrat ou sa fin prononcée par le juge, l'article 1195 alinéa 2 du Code civil permettant à celui-ci de réviser le contrat ou d'y mettre fin. Le premier gère une demande d'évolution, le second un bouleversement subi de l'économie du contrat.
Peut-on démarrer les travaux d'une évolution avant la signature de l'avenant ?
C'est déconseillé. Tant que l'accord n'est pas formé, l'article 1193 du Code civil prive la modification de force obligatoire : le prestataire travaille sans base pour être payé ni délai opposable, le client sans garantie sur le prix. La clause doit interdire tout démarrage avant validation écrite et prévoir que le silence ne vaut pas acceptation. En cas d'urgence, un bon de commande simplifié daté et signé sécurise le lancement.