Comment gérer juridiquement les demandes de modifications dans les projets de développement informatique?
Un des points de friction les plus répandus dans les relations entre les entreprises de développement et de programmation informatique et leurs clients est lié aux modifications sollicitées par le client en cours de développement du projet. Redoutées par les prestataires, considérées comme normales par leur clientèle elles donnent souvent lieu à des litiges. Le prestataire souhaite facturer le surplus de développement requis, le client considère, lui, qu'il s'agit d'une extorsion de fonds alors qu'il ne demande que de "petites modifications de rien du tout"... Comment gérer la difficulté sur le plan juridique? Peut-on éviter le litige? Réponse : oui! En prévoyant au contrat la notion d’ « évolution ».
C'est un grand classique : le client vous a exposé son projet. Et fatalement, en cours de développement, il le modifie. Un peu comme si il vous commandait une maison comportant 3 chambres et un garage et qu'en cours de construction, il vous réclame en plus (et souvent pour le même prix...) une piscine et une salle de home cinéma.
Or, tout développeur le sait, une demande de modification peut avoir de lourdes conséquences en terme de contraintes techniques, horaires et donc financières. Mais ça, votre client a bien souvent du mal à le comprendre. Mais si vous lui dites très tôt, à savoir, dans le contrat de commande, alors vous limitez le risque de frictions par la suite puisque son attention aura été attirée sur ce point... et gérée en amont!
Intégrer la notion "d’évolution" impose d'abord un cahier des charges bien construit. Ce que l'on nomme souvent "l’expression des besoins" du client sera donc, a minima, fournit par le prestataire pour donner corps à ses demandes. A défaut, pas la peine d’envisager de cadrer par le contrat ensuite les demandes de modifications du projet.
Dès le début du contrat, cette notion doit figurer dans les définitions explicitant la sémantique utilisée dans le corps de celui-ci : on pourra la rédiger ainsi : "EVOLUTION(S) : demande de modification et/ou de rajout d’une fonctionnalité pour le projet émanant du client et ne figurant pas au cahier des charges (ou dans l'expression de besoins)."
On rajoutera ensuite une clause spécifique sur cette notion "d’évolution" : en bon langage contractuel, ça nous donne :
« L’attention du client est attirée sur la notion d’EVOLUTION. Toute demande de modification du client ne rentrant pas dans le cadre du cahier des charges (ou "expression de besoins") est susceptible de revêtir la qualification d’EVOLUTION, laquelle entraîne, en raison de l’imprévision initiale de la demande, un risque de modification du planning des réalisations des prestations figurant au cahier des charges (ou "expression de besoins") et donc la nécessité pour le prestataire de procéder à un ajustement tarifaire en raison du temps supplémentaire généré pour réaliser la demande nouvelle du client que constitue l’EVOLUTION.
Toute EVOLUTION pourra donner lieu à une nouvelle discussion des parties pour déterminer le surcoût induit par la nouvelle demande ainsi que la redéfinition du planning constituant l’ANNEXE XX, lequel pourra, avec l’accord réciproque des parties, être modifié en fonction des besoins ainsi exprimés et remplacer le planning initialement conclu.
Tout accord conclu dans le cadre d’une discussion visée à cet article devra donner lieu à un avenant écrit et signé des parties puis annexé au contrat. A défaut de signature d’un accord par les deux parties, le caractère d’EVOLUTION ne pourra pas être retenu, ni donner lieu à une facturation supplémentaire. »
Gestion de la demande modificative, gestion des modifications ainsi induites sur le planning de développement, gestion du surcroût induit... voilà comment protocoliser juridiquement cet aspect d'une commande client en matière de développement informatique.
Le désordre causé par l’évolution nécessaire ou fortuite du projet n’est donc pas une fatalité. On peut parfaitement la gérer avec un contrat bien rédigé…
Encore une bonne recette à base d’avocat pour déguster tranquillement vos projets… et bon appétit bien sûr!
Or, tout développeur le sait, une demande de modification peut avoir de lourdes conséquences en terme de contraintes techniques, horaires et donc financières. Mais ça, votre client a bien souvent du mal à le comprendre. Mais si vous lui dites très tôt, à savoir, dans le contrat de commande, alors vous limitez le risque de frictions par la suite puisque son attention aura été attirée sur ce point... et gérée en amont!
Intégrer la notion "d’évolution" impose d'abord un cahier des charges bien construit. Ce que l'on nomme souvent "l’expression des besoins" du client sera donc, a minima, fournit par le prestataire pour donner corps à ses demandes. A défaut, pas la peine d’envisager de cadrer par le contrat ensuite les demandes de modifications du projet.
Dès le début du contrat, cette notion doit figurer dans les définitions explicitant la sémantique utilisée dans le corps de celui-ci : on pourra la rédiger ainsi : "EVOLUTION(S) : demande de modification et/ou de rajout d’une fonctionnalité pour le projet émanant du client et ne figurant pas au cahier des charges (ou dans l'expression de besoins)."
On rajoutera ensuite une clause spécifique sur cette notion "d’évolution" : en bon langage contractuel, ça nous donne :
« L’attention du client est attirée sur la notion d’EVOLUTION. Toute demande de modification du client ne rentrant pas dans le cadre du cahier des charges (ou "expression de besoins") est susceptible de revêtir la qualification d’EVOLUTION, laquelle entraîne, en raison de l’imprévision initiale de la demande, un risque de modification du planning des réalisations des prestations figurant au cahier des charges (ou "expression de besoins") et donc la nécessité pour le prestataire de procéder à un ajustement tarifaire en raison du temps supplémentaire généré pour réaliser la demande nouvelle du client que constitue l’EVOLUTION.
Toute EVOLUTION pourra donner lieu à une nouvelle discussion des parties pour déterminer le surcoût induit par la nouvelle demande ainsi que la redéfinition du planning constituant l’ANNEXE XX, lequel pourra, avec l’accord réciproque des parties, être modifié en fonction des besoins ainsi exprimés et remplacer le planning initialement conclu.
Tout accord conclu dans le cadre d’une discussion visée à cet article devra donner lieu à un avenant écrit et signé des parties puis annexé au contrat. A défaut de signature d’un accord par les deux parties, le caractère d’EVOLUTION ne pourra pas être retenu, ni donner lieu à une facturation supplémentaire. »
Gestion de la demande modificative, gestion des modifications ainsi induites sur le planning de développement, gestion du surcroût induit... voilà comment protocoliser juridiquement cet aspect d'une commande client en matière de développement informatique.
Le désordre causé par l’évolution nécessaire ou fortuite du projet n’est donc pas une fatalité. On peut parfaitement la gérer avec un contrat bien rédigé…
Encore une bonne recette à base d’avocat pour déguster tranquillement vos projets… et bon appétit bien sûr!
