Les commentaires de l'auteur du mémoire sont en bleu,
entre des barres dégradées bleues, les commentaires des auteurs
du contrat sont en orange.
Les auteurs de ce contrat déclinent toute
responsabilité quant à l'utilisation qui en est faite.
Notice : Le contrat contient des zones éditables et des
zones de commentaire.
Société <forme juridique> au capital social
de <montant> euros, inscrite au RCS de <ville> sous le
numéro <numéro>, dont le siège social est sis
<adresse>.
Représentée par <nom>, agissant en sa
qualité de <statut>, dûment habilité à l'effet
des présentes.
Représentée par le signataire du présent
contrat, dûment habilité à l'effet des présentes.
Le CLIENT souhaite faire développer une solution de
plus grande qualité. Il s'est donc intéressé aux
méthodes agiles dans le souci de rester maître de ce
développement et de ses contraintes afférentes
1. PRÉAMBULE
1.1. LE PRESTATAIRE
Le Prestataire est <description de la société
Prestataire en quelques lignes>. 1.2. LES MÉTHODES
AGILES
Les méthodes agiles sont des groupes de pratiques
utilisées notamment dans le cadre des projets de développement de
logiciels. Ces méthodes (Scrum, XP) tendent depuis leur apparition dans
les années 90 à supplanter les méthodes traditionnelles
(méthodes en cascade) en ce qu'elles permettent, grâce au cycle de
développement itératif, incrémental et adaptatif, une
approche plus pragmatique des besoins du client en autorisant une
réactivité permanente à ses demandes et aux besoins
évolutifs des utilisateurs, ce qui permet de privilégier la
réalisation d'un produit véritablement opérationnel,
à moindre coût, dans un délai contraint.
Les principes de ces méthodes agiles ont
été exprimés en 2001 dans le Manifeste Agile. Ce manifeste
prône quatre valeurs fondamentales :
(( Anomalie Bloquante » :
désigne toute Anomalie qui provoque l'impossibilité d'utiliser au
moins une fonction du Développement ou du Logiciel.
(coût, délai, périmètre
évolutif).
Le CLIENT après avoir étudié les
bénéfices de ces méthodes considère qu'elles
répondent à ses besoins et objectifs :
o disposer d'une méthodologie adaptative, lui
permettant de bénéficier d'une organisation informatique claire
et pertinente ;
o adapter le logiciel à ses besoins métier,
voire changer d'avis, même pendant la phase de développement de
celui-ci et au besoin mettre fin au projet s'il estime que celui-ci remplit ses
objectifs en cours de réalisation.
Il a, enfin, une parfaite conscience que la maximisation de
la valeur produite par le logiciel, née de l'application des
méthodes agiles (livraisons fréquentes, implication du client, la
gestion des priorités basées sur des estimations de valeur et de
coût) nécessite de sa part une grande implication dans la conduite
du changement qu'induit l'introduction de ces méthodes dans son
entreprise.
C'est pour ces raisons que, connaissant bien les
méthodes agiles, et estimant qu'elles lui permettront une parfaite
maîtrise des coûts et des délais et une grande souplesse
d'adaptation à ses besoins en cours de développement, le CLIENT
s'est tourné vers LE PRESTATAIRE.
LE PRESTATAIRE a maintenu à la disposition du CLIENT
les informations techniques et commerciales relatives à sa
méthodologie de développement pour permettre au CLIENT de
confirmer, si besoin en était, que celle-ci est de nature à
répondre à ses objectifs. LE PRESTATAIRE est également
resté à la disposition du CLIENT pour répondre à
toute demande d'information et procéder à toute
démonstration que celui-ci a pu requérir.
Dans ces conditions, le CLIENT a établi et transmis au
PRESTATAIRE un cahier des charges exprimant ses besoins en termes de
fonctionnalités attendues du logiciel. Ce cahier des charges a
été reformulé sous la forme de deux documents : Vision
(Annexe 2) et Product Backlog V.0 (Annexe 7).Sur la base de ces documents, LE
PRESTATAIRE a réalisé une estimation de charges, structure et
délais qui est jointe à l'Annexe 3.
Après discussion sur la base de ces documents, les
Parties se sont accordées sur les termes du présent contrat dont
le préambule fait partie intégrante et dispose de la même
valeur que les autres dispositions.
2. DEFINITIONS
Dans le cadre du présent contrat, les termes
ci-après avec une majuscule, au singulier ou au pluriel, ont
été définis de la manière suivante :
(( Anomalie » : désigne toute
anomalie de fonctionnement d'un Développement ou du Logiciel qui
consiste en une différence entre le fonctionnement constaté du
Développement ou du Logiciel et celui décrit dans le Sprint
Backlog pour le Développement ou dans le Product Backlog pour le
Logiciel et qui est exclusivement imputable au Développement ou au
Logiciel, reproductible et documenté par le CLIENT.
« Sprint » : désigne la
séquence de base de réalisation d'un Développement qui est
d'une courte durée
« Anomalie Majeure » :
désigne toute Anomalie qui génère une dégradation
importante d'au moins une fonction du Développement ou du Logiciel ou
des performances.
« Anomalie Mineure » :
désigne toute Anomalie autre qu'une Anomalie Bloquante ou une Anomalie
Majeure qui ne gêne pas l'utilisation du Développement ou du
Logiciel et ne dégrade pas leurs performances.
« Vision » : désigne le
document établi par le CLIENT avec l'aide du PRESTATAIRE dans lequel
celui-ci a consigné les objectifs du projets et les grande
fonctionnalités. Le document présentant cette « vision
» est joint en Annexe 2. Ce document peut être assimilé
à une version, modifiée conformément aux principes agiles,
du traditionnel « cahier des charges ».
« Développement » :
désigne le programme informatique, en code source et en code objet, qui
a vocation à implémenter les fonctions définies dans un
Sprint Backlog et qui est délivré à l'issue du Sprint
afférent. Le Développement est une subdivision fonctionnelle du
Logiciel.
« Logiciel » ou « Product »
: désigne le programme informatique final, en code source,
regroupant l'ensemble des Développements qui a vocation à
implémenter les fonctions définies dans le Product Backlog, ainsi
que la documentation d'exploitation afférente.
« Niveaux de Service » :
désigne le nombre d'unités de mesure associé à
certaines des prestations de service quantifiables prévus dans le Plan
Qualité de Service. Les Niveaux de Service faisant l'objet d'un
engagement de la part du PRESTATAIRE sont expressément visés dans
ledit Plan Qualité de Service.
« Plan Qualité de Service » ou «
PQS » : désigne le document qui précise la
méthodologie mise en place pour satisfaire les besoins exprimés
par le CLIENT en matière de qualité des services fournis dans le
cadre du présent contrat. A cet effet, le Plan Qualité de Service
décrit la façon dont sont organisées les relations entre
les Parties, la liste des tâches incombant à chaque Partie au
titre du présent contrat et leur survenance dans le temps ainsi que les
Niveaux de Service sur lesquels LE PRESTATAIRE accepte de s'engager pour la
réalisation de ses prestations dans le cadre du présent contrat
ainsi que les éventuelles pénalités qui y sont
associées. Le Plan Qualité de Service sera établi par LE
PRESTATAIRE pendant la phase de lancement et sera soumis pour validation au
Comité de Pilotage. Toutefois, une version initiale du Plan
Qualité de Service est jointe en Annexe 4.
« Story Point » : désigne
l'unité de mesure du périmètre d'un logiciel en termes de
fonctionnalités. « Product Backlog » :
désigne la liste priorisée des fonctionnalités du
produit.
« Product Owner » : désigne
le membre du personnel du CLIENT qui est l'interlocuteur
privilégié et à disposition de l'équipe de
développement du PRESTATAIRE. Le Product Owner doit posséder une
expertise fonctionnelle métier et le pouvoir nécessaire pour
engager le CLIENT aux fins de prendre les décisions nécessaires
au bon déroulement de la réalisation des Développements et
du Logiciel.
« Scrum Master» : désigne
le membre de l'équipe de développement du PRESTATAIRE qui est
l'animateur de cette équipe. Il a la charge d'optimiser la
capacité de production de cette équipe en l'aidant à
travailler de façon autonome et à s'améliorer au fil du
temps et de traiter les obstacles qui ralentissent ou empêchent
l'équipe de travailler, le cas échéant, en demandant au
CLIENT de les supprimer.
« Spécifications » :
désigne les spécifications fonctionnelles apportant des
compléments au Product Backlog pour le Logiciel et dans les Sprint
Backlogs pour les Développements.
(à titre indicatif, de l'ordre de 2 à 4
semaines). Un Sprint débute par un Sprint Planning et se termine par un
Sprint Review.
(( Sprint Backlog » : désigne la
liste des fonctionnalités à réaliser lors d'un sprint et
la liste des tâches correspondantes qui sont établies à
l'occasion d'un Sprint Planning. La charge afférente à chaque
tâche est déterminée par l'équipe de
développement du PRESTATAIRE.
(( Sprint Planning » : désigne
la réunion de l'équipe de développement du PRESTATAIRE et
du Product Owner qui a lieu au début de chaque Sprint pour
déterminer l'objectif et le contenu de celui-ci et qui permet
d'établir le Sprint Backlog.
(( Sprint Review » : désigne la
réunion de l'équipe de développement du PRESTATAIRE et du
Product Owner qui a lieu à l'issue de chaque Sprint pour l'essentiel
afin de faire une démonstration du Développement et d'ajuster le
contenu du Product Backlog en fonction des souhaits exprimés par le
CLIENT.
"Rétrospective" : désigne la réunion qui
a lieu à l'issue de chaque Sprint et dont l'objectif est discuter des
axes d'améliorations de l'équipe. Sont présents à
cette réunion : le Scrum Master, l'équipe, et le Product Owner.
Épisodiquement, d'autres acteurs comme le Directeur de Projet
PRESTATAIRE peuvent être invités à cette réunion.
3. OBJET DU CONTRAT
3.1. Le présent contrat a pour objet de
définir les conditions dans lesquelles et les modalités selon
lesquelles LE PRESTATAIRE s'est engagée à
réaliser les prestations de développement du Logiciel :
o en utilisant la méthodologie décrite en Annexe 1
;
o conformément au Product Backlog (Annexe 7 pour
mémoire) et à la Vision joint en Annexe 2 ;
o conformément au Plan Qualité de Service
présenté à l'article 6 et dont la version initiale est
jointe en Annexe 4 ;
o dans le respect de l'estimation de charges, structure et
délais jointe à l'Annexe 3, le cas échéant
modifiée dans les conditions du présent contrat ;
o selon les conditions particulières et
financières de l'Annexe 5.
3.2. Le présent contrat est régi
par les dispositions de l'article 1779 3° du Code Civil.
Le présent contrat est dépourvu de tout
affectio societatis et n'aura aucun effet sur l'indépendance de chaque
Partie en ce qui concerne l'exercice de son activité et la poursuite de
son objet social, chaque Partie continuant à exercer en toute
indépendance sa gestion, ses droits
et ses obligations et à assumer ses
responsabilités. A ce titre, il ne peut en aucun cas
être
interprété comme créant entre les Parties un
lien d'associés, une relation de mandat ou comme un contrat de location
gérance ou même de sous-traitance de l'activité du CLIENT.
Il est exclusif de toute notion de mise à disposition de personnel
entrant dans le cadre de la réglementation sur le travail temporaire.
4.1. L'accord conclu entre les parties comprend par ordre de
valeur juridique décroissante :
4. DOCUMENTS CONTRACTUELS
o le présent contrat, les Conditions
Particulières jointes en Annexe 5 et l'estimation de charges, structure
et délais jointe en Annexe 3 dans sa version V0, le cas
échéant modifiée dans les conditions du présent
contrat ;
o la Méthodologie Agile jointe en Annexe 1 ;
o le Plan Qualité de Service dans sa dernière
version, approuvée par le Comité de Pilotage, qui annulera et
remplacera la version V0 jointe en Annexe 4 ;
o le Product Backlog ;
o La vision, jointe en Annexe 2.
Ces documents sont désignés ci-après
ensemble par le « Contrat ».
4.2. En cas de contradiction entre deux ou
plusieurs des documents ci-dessus, le document situé le
plus haut dans la hiérarchie contractuelle
prévaudra, que ladite contradiction soit volontaire ou non. En cas de
document susceptible de faire l'objet de versions successives, la version la
plus récente du document prévaudra.
4.3. Les versions successives des documents
approuvés en Comité de Pilotage, ont la même valeur
contractuelle que le document initial (V0) et prendront place
de la précédente version annulée et remplacée par
la dernière version approuvée en Comité de Pilotage.
4.4. Les éventuels avenants au Contrat
devront indiquer leur rang dans la hiérarchie contractuelle. À
défaut, ils auront le rang du document qu'ils ont pour
objet de modifier et, en cas de pluralité de documents modifiés
par le même avenant, le rang du document amendé le moins
élevé dans la hiérarchie contractuelle. Si un avenant
n'indique pas son rang dans la hiérarchie contractuelle et qu'il n'a pas
pour objet de modifier un ou plusieurs documents déjà existants,
il acquerra automatiquement le rang le moins élevé dans la
hiérarchie contractuelle.
4.5. Par ailleurs, dans l'hypothèse
où une disposition du Contrat serait considérée comme
nulle,
invalide ou inapplicable, par une loi, un règlement ou
une décision de justice passée en force de chose jugée,
elle sera réputée non écrite et les autres dispositions du
Contrat garderont toute leur force et leur portée. Les Parties
s'efforceront dans un délai de un (1) mois, à compter de
l'événement ayant entraîné la nullité,
l'invalidité ou l'inapplicabilité de la clause, de s'accorder sur
les termes d'une clause de remplacement respectant l'esprit et
l'économie de la clause précédente, et plus
généralement du Contrat, et conformément aux règles
d'interprétation des articles 1156 et suivants du Code civil.
5. MISE EN OEUVRE DES PRESTATIONS
5.1. DÉCOUPAGE DES PRESTATIONS
La réalisation des prestations objet du Contrat
comprendra une phase de lancement puis une phase opérationnelle et, le
cas échéant, une phase de finalisation.
5.1.1. Phase de lancement
La phase de lancement comprend les prestations initiales de
mise en place des conditions méthodologiques, organisationnelles,
matérielles et humaines en vue de la réalisation des prestations
de développement du Logiciel.
La phase de lancement permet également d'actualiser le
périmètre fonctionnel du Logiciel consigné dans la Vision
sur la base duquel LE PRESTATAIRE a produit son estimation de charges,
structure et délais et, le cas échéant, d'ajuster ces
documents.
La phase de lancement comprend les opérations suivantes
:
o Établissement du Plan Qualité de Service.
o Réalisation du Sprint 0 qui recouvre notamment :
? La présentation des personnels du PRESTATAIRE et du
CLIENT impliqués dans la
réalisation des prestations objet du Contrat.
? La mise en place de la Méthodologie AGILE
présentée en Annexe 1.
? La mise en place de l'infrastructure de développement
et de l'usine logicielle choisies
par LE PRESTATAIRE.
? L'ajustement par LE PRESTATAIRE de l'estimation de
charges, structure et délais à la
hausse ou à la baisse
conformément aux Conditions Particulières.
? La revue du Product Backlog.
? L'établissement du contenu du Sprint suivant.
o Réalisation des Sprints 1 à 3 : Les sprints 1
à 3 sont des sprints de production dont les objectifs sont :
o Délivrer des incréments de logiciels.
o Stabiliser les indicateurs et métriques
associées choisis dans le PQS. A l'issue du sprint 3, PRESTATAIRE
s'engage sur la valeur définitive des seuils d'alerte pour chaque
indicateur.
5.1.2. Phase opérationnelle
La phase opérationnelle des prestations de
développement du Logiciel est composée de Sprints successifs
à l'issue desquels LE PRESTATAIRE délivrera un
Développement qui devra être validé
par le CLIENT selon la procédure de réception des
Développements visée à l'article 9.
La phase opérationnelle des prestations
s'achèvera par la délivrance du Logiciel par LE PRESTATAIRE qui
devra être validé par le CLIENT en vertu de la procédure de
réception du Logiciel visée à l'article 8.
5.1.3. Phase de finalisation
Si le CLIENT met en oeuvre la procédure
résultant des dispositions de l'article 17.2 du Contrat « ATTEINTE
ANTICIPÉE DES OBJECTIFS DU CLIENT », les Parties poursuivront
l'exécution du Contrat pendant deux Sprints de manière à
finaliser la mise au point des Développements issus du dernier Sprint
exécuté ou en cours d'exécution au jour de la
décision du CLIENT.
Les Sprint Backlogs de ces deux derniers Sprints seront
arrêtés par le Comité de Pilotage.
5.2. LIEU D'EXÉCUTION DES PRESTATIONS
Le lieu d'exécution des prestations est fixé aux
Conditions Particulières.
5.3. PERSONNELS AFFECTÉS À LA RÉALISATION
DES PRESTATIONS
5.3.1. Les personnels du PRESTATAIRE,
même s'ils venaient à être détachés dans les
locaux du CLIENT, resteront en toutes circonstances sous l'autorité
hiérarchique et disciplinaire du PRESTATAIRE qui est leur seul employeur
et qui assumera la gestion sociale, administrative et comptable de celui-ci.
A ce titre, LE PRESTATAIRE devra obtenir tous passeports,
visas, permis de travail, autorisations et autres documents nécessaires
à l'emploi de ses personnels.
LE PRESTATAIRE sera seul responsable de la répartition
des tâches, de la programmation des tâches et de l'acceptation des
tâches réalisées par ses personnels.
Les absences des personnels, pour quelque motif que ce soit,
et notamment maladie, formation et congés, seront autorisées
et/ou gérées par LE PRESTATAIRE. Cette dernière devra
toutefois veiller à :
? informer le CLIENT de l'absence d'un membre du personnel
dans les meilleurs délais et rechercher avec lui une solution permettant
d'assurer la continuité des prestations ;
? autoriser les périodes de congé ou de
formation des personnels en concertation avec le CLIENT en vue du bon
déroulement des prestations.
5.3.2. En aucune manière les
personnels du PRESTATAIRE ne sauraient être soumis à un quelconque
lien de subordination émanant du CLIENT et, réciproquement, les
personnels du CLIENT en contact avec LE PRESTATAIRE ne sauraient être
soumis à l'autorité, ni à la subordination de cette
dernière.
Cette clause ne suffit pas à éviter
toute infraction à la législation sociale (travail
dissimulé et prêt de main d'oeuvre illicite), les stipulations qui
y figurent doivent impérativement être respectées (voir II,
1.2).
5.4. ENVIRONNEMENT TECHNIQUE
A compléter : Description de l'environnement
technique du projet
Le CLIENT fournira au PRESTATAIRE toutes autres ressources
humaines, techniques, logistiques et organisationnelles nécessaires
à la bonne exécution des prestations de développement du
Logiciel.
6. PLAN QUALITE DE SERVICE
6.1. Les relations entre les Parties, notamment au sein du
Comité de Pilotage, le déroulement des
Sprints, le détail des rôles et
responsabilités de chaque Partie seront précisés dans le
Plan Qualité de Service qui sera réalisé pendant la phase
de lancement.
6.2. Le Niveau de Service fourni au CLIENT
sera également défini dans le Plan Qualité de Service
pendant la phase de lancement. Il contiendra la liste des
valeurs mesurables permettant d'exprimer de manière factuelle le niveau
du service rendu. L'obligation contractuelle du PRESTATAIRE, quant à la
qualité du service, sera ainsi énoncée par ces grandeurs
objectivement mesurables et représentatives. Le Plan Qualité de
Service précisera également comment et avec quelle
fréquence seront mesurés les indicateurs concernés.
6.3. {Le Plan Qualité de Service
prévoira les pénalités contractuelles applicables en cas
de non
atteinte d'un Niveau de Service.
Le fait générateur d'une
pénalité sera un écart constaté entre le Niveau de
Service d'une prestation effectivement mesuré à l'aide d'un
indicateur défini au Plan Qualité de Service et le Niveau de
Service souscrit pour ladite Prestation.
Les pénalités seront calculées sur une
base périodique à partir des formules de calcul exposées
dans la Plan Qualité de Service.
Les pénalités ne seront pas applicables
dans les cas de non responsabilité du PRESTATAIRE visés à
l'article 10 et, en tout état de cause, lorsque la non-atteinte d'un
Niveau de Service n'est pas imputable à un manquement du PRESTATAIRE
à ses obligations contractuelles.
A la fin de la périodicité prévue
dans le Plan Qualité de Service, les pénalités seront
consolidées dans un document qui donnera lieu à une
réunion du Comité de Pilotage. Au cours de cette réunion,
LE PRESTATAIRE indiquera celles des pénalités qui selon elle ne
devraient pas être appliquées, en particulier, lorsque LE
PRESTATAIRE estimera qu'elle n'est pas responsable de la non atteinte du Niveau
de Service d'une prestation.
A l'issue de cette réunion, le CLIENT
décidera, dans un délai de cinq (5) jours ouvrés, des
pénalités qu'il appliquera effectivement et de celles qu'il
abandonne. Pour celles que le CLIENT appliquera, il devra émettre une
demande par lettre recommandée avec accusé de réception
adressée au PRESTATAIRE. Les pénalités non
réclamées dans le délai susvisé seront
réputées abandonnées par le CLIENT.
En tout état de cause, le montant consolidé
de toutes les pénalités sur la période
considérée sera plafonné un pourcentage (défini
dans l'Annexe Financière) du montant de la dernière facture en
date émise par LE PRESTATAIRE.
Les avoirs émis au titre des
pénalités constituent une indemnité forfaitaire de
dommages-intérêts pour ce qui concerne les manquements du
PRESTATAIRE à l'origine desdites pénalités.}
6.4. Une version initiale V 0 du Plan
Qualité de Service est fournie en Annexe 4.
7. INTERLOCUTEURS PRIVILÉGIÉS - COMITE DE
PILOTAGE
7.1. En complément des rôles
traditionnels décrits en Annexe 1, chacune des Parties s'engage à
désigner un interlocuteur privilégié chargé des
relations avec l'autre Partie.
Le CLIENT désignera un interlocuteur responsable
(dénommé ci-après le « Chef de Projet CLIENT »),
ayant une connaissance approfondie de l'organisation du CLIENT et de l'ensemble
des besoins du CLIENT. Cet interlocuteur devra disposer des pouvoirs suffisants
pour prendre les décisions engageant le CLIENT.
8. RÉCEPTION DES DÉVELOPPEMENTS ET DU
LOGICIEL
Cet interlocuteur aura principalement les missions suivantes :
o Définition de la stratégie
générale du système d'information et du budget
informatique.
o Conduite du changement.
o Suivi de la qualité des prestations sur la base des
indicateurs définis dans le Plan Qualité de Service.
o Participation aux Comités de Pilotage.
LE PRESTATAIRE désignera un interlocuteur
(dénommé ci-après le « Directeur de Projet du
PRESTATAIRE ») qui aura principalement les missions suivantes :
o Responsabilité de la fourniture des prestations dans le
respect des engagements du présent contrat.
o Coordination de l'équipe opérationnelle du
PRESTATAIRE.
o Production des documents de suivi de projet.
o Participation et animation des Comités de Pilotage.
o Recouvrement des créances.
En fonction de la taille du projet les Conditions
Particulières peuvent prévoir que :
o Les rôles de Chef de projet CLIENT et de Product Owner
pourront être assumés par la même personne,
o Les rôles de Directeur de Projet DU PRESTATAIRE et de
Scrum Master pourront être assumés par la même personne.
7.2. Le Comité de Pilotage
réunira à minima le Product Owner, le Scrum Master, le Chef de
Projet
Client et le Directeur de Projet du PRESTATAIRE ainsi que tout
intervenant jugé nécessaire, à l'initiative du CLIENT ou
du PRESTATAIRE, et aura pour objet :
o D'assurer le suivi des prestations et du Plan Qualité
de Service notamment via les indicateurs de qualité.
o D'assurer le traitement et le suivi des obstacles survenus et
des plans d'actions proposés pour les résoudre.
o De contrôler l'exécution du budget
arrêté.
o De faire une revue des factures impayées et d'examiner
les éventuelles contestations formulées par le CLIENT en ce qui
concerne la facturation.
o D'assurer la recherche de l'amélioration continue en
prenant en compte les réunions de rétrospective menées
à l'issue de chaque Sprint.
7.3. Le Comité de Pilotage se
réunira selon la périodicité définie au Plan
Qualité de Service. Des
réunions supplémentaires pourront être
demandées par l'une ou l'autre des Parties en cas de besoin.
A l'issue de chacune des réunions, LE PRESTATAIRE
rédigera, dans un délai d'une (1) semaine, un compte rendu dont
le texte sera réputé approuvé par le CLIENT si aucune
modification n'est demandée dans la semaine qui suit la
réception.
8.1. LIVRAISON
LE PRESTATAIRE s'engage à livrer à la fin de
chaque Sprint et à la fin du projet :
o Le code des Développements, et à la fin du
projet, du Logiciel à date.
o Les actifs des tests unitaires et fonctionnels à
date.
o Les scripts de construction et de déploiement.
o Les Spécifications afférentes aux
Développements, et à la fin du projet, du Logiciel.
o Le rapport d'exécution des tests unitaires.
o Le bon de livraison détaillant les
Développements livrés.
8.2. RECETTE
8.2.1. Objet
Le CLIENT procèdera à la recette des
Développements ou du Logiciel à compter de la livraison du code,
des Spécifications afférentes et du rapport d'exécution
des tests unitaires.
La procédure de recette a pour objectif de
contrôler que les Développements ou le Logiciel sont conformes aux
attentes spécifiées dans le Backlog de Sprint.
Le CLIENT s'engage, par conséquent, à mettre
à disposition des personnels du PRESTATAIRE affectés à la
réalisation des prestations, des personnels dûment
assermentés et compétents.
8.2.2. Recettes incrémentales
Pour garantir le respect des fonctionnalités, le
CLIENT devra opérer la recette du Développement issu d'un Sprint
N au plus tard avant la fin du Sprint N+1. En l'absence d'acceptation expresse,
de réserves ou de refus émis dans ce délai, le
démarrage du Sprint N+2 vaudra recette tacite du Développement
issu du Sprint N.
8.2.3. Recette définitive
Le Client devra opérer la recette définitive du
Logiciel livré au plus tard trente (30) jours calendaires après
la dernière livraison. En l'absence d'acceptation expresse, de
réserves ou de refus émis dans ce délai, la mise en
production du Logiciel vaudra recette tacite de celui-ci. En tout état
de cause, la recette définitive du Logiciel sera réputée
prononcée à l'expiration du délai de trente (30) jours
calendaires à compter de la dernière livraison.
8.2.4. Procédure
La procédure de recette est définie en
détail dans le POS.
Au terme de la procédure de recette définitive,
le CLIENT émettra un procès-verbal de recette donnant lieu :
o soit à une acceptation sans réserve du Logiciel
;
o soit à une acceptation avec réserves du Logiciel
;
o soit à un refus.
Tout procès-verbal de recette sans réserve
entraîne réception du Logiciel livré.
La durée maximale de la procédure de recette
définitive du Logiciel est fixée à quatre (4) semaines
calendaires.
