Vous êtes sur la page 1sur 24

Marché n° 2010-021

Développement et maintenance
d’une plateforme internet collaborative

Cahier des clauses particulières

Pouvoir adjudicateur

Haute Autorité pour la diffusion des œuvres et la protection des droits sur internet (Hadopi)
4, rue du Texel, 75014 PARIS

Modalités de la consultation

Procédure ouverte non formalisée en application de l’article 10 du décret n° 2005-1742 du 30


décembre 2005

Interlocuteur

Madame Elsa Hervy

Directrice des Finances et du Développement


Article 1 – Contexte

La Haute Autorité pour la diffusion des œuvres et la protection des droits sur internet (Hadopi
ou Haute Autorité) est une autorité publique indépendante créée par la loi n° 2009-669
favorisant la diffusion et la protection de la création sur internet.

L’Hadopi est investie des missions suivantes :

- Encouragement au développement de l’offre légale et observation de l’utilisation licite


et illicite d’œuvres et d’objets protégés par un droit d’auteur ou par un droit voisin sur
les réseaux de communications électroniques (sous-section 2 du code de la propriété
intellectuelle) ;

- Protection des œuvres et objets auxquels est attaché un droit d’auteur ou un droit
voisin à l’égard des atteintes à ces droits commises sur les réseaux (sous-section 3
du code de la propriété intellectuelle) ;

- Régulation et veille dans le domaine des mesures techniques de protection et


d’identification des œuvres et des objets protégés par un droit d’auteur ou un droit
voisin (sous-section 4 du code de la propriété intellectuelle).

Article 2. ‒ Objet du marché

Le présent marché a pour objet la conception, le développement et la maintenance d’une


plateforme internet collaborative.

Le titulaire du marché devra :

- Définir l’architecture technique de la plateforme sur la base du besoin fonctionnel


exprimé dans le présent document. La solution doit préférablement s’appuyer sur des
outils existants, issus de logiciels o
- pen-source. Elle sera adaptée au volume des visites attendu et aux contraintes de
sécurité.

- Déployer et paramétrer la solution retenue, l’adapter si nécessaire (développements


spécifiques ou mise en place d’extensions).

- Concevoir l’ergonomie de l’interface utilisateur en fonction des préconisations


fonctionnelles et décliner la charte graphique Web de la Haute Autorité sur la partie
« front-office » de la solution.

- Héberger temporairement la plateforme jusqu’à sa migration.

2
- Accompagner la Haute Autorité dans la migration de cette plate-forme vers un
prestataire d’hébergement.
- Former les utilisateurs à la gestion de la plateforme : alimentation, modération, etc.

- Assurer la maintenance technique de la plate-forme pour une durée d’un an


reconductible pendant toute la durée du marché.

Article 3. ‒ Présentation du projet

Les Labs de l’Hadopi

Les Labs de la Haute Autorité sont des ateliers de recherche confiés a des experts
indépendants nommés par le Collège de l’Hadopi. Ils fonctionnent en mode collaboratif
ouvert. Ils appuient la mission de la Haute AutoritéZ , ils sont destinés a construire une
expertise approfondie des différentes composantes qui, dans leur globalitéZ , constituent «
l’écosystème » dans lequel elle évolue.

Les Labs ont, notamment, pour objectif de construire une base de connaissances accessible
a tous, regroupant des publications de référence rédigées selon une méthode collaborative,
permettant d’élaborer des propositions de résolution des tensions existantes.

Au cœur du processus de travail des Labs : une méthode collaborative qui permet a la Haute
AutoritéZ d’entretenir un lien étroit avec les internautes, notamment par la sollicitation
d’experts qui contribuent a enrichir les travaux, comme avec les autres établissements,
institutions, centres de recherches, universités et écoles, etc. qui, dans leur ensemble,
contribuent a l’enrichissement de la connaissance relative a l’internet et la propriété
intellectuelle.

Anticipant les prochaines évolutions du Net, la plateforme est construite selon les principes
du Web sémantique (Web 3.0 - qui facilite l’accès aux données et leur partage) et du Web dit
« participatif » (ou Web 2.0 - qui invite l’internaute a contribuer a l’élaboration des contenus).

Article 4. ‒ Nature du marché

Le présent marché est passé selon une procédure non formalisée, en application de l’article
10 du décret n° 2005-1742 du 30 décembre 2005 fixant les règles applicables aux marchés
passés par les pouvoirs adjudicateurs mentionnés à l’article 3 de l’ordonnance n° 2005-649
du 6 juin 2005 relative aux marchés passés par certaines personnes publiques ou privées
non soumises au code des marchés publics.

Le présent marché est un marché à forfait pour la partie conception, développement et


maintenance de la plateforme et un marché à bons de commande, en application de l’article

3
43 du décret de 2005 précité, sans montant d’engagement minimum pour les
développements supplémentaires éventuels étant entendu que le montant total du marché
ne saurait excéder 193 000 euros H.T.

L’Hadopi se réserve le droit de négocier sur la base des offres des candidats.

Article 5. ‒ Pièces constitutives du marché

Le présent marché est régi par l’ensemble des documents énumérés ci-dessous, par ordre
de priorité décroissante :

a) L’acte d’engagement ;

b) Le présent cahier des clauses particulières paraphé et signé par le titulaire dont
l’exemplaire original conservé dans les archives de la Haute Autorité fait seul foi ;

c) Le cahier des clauses administratives générales applicables aux marchés publics de


prestations intellectuelles (CCAG/PI) option B, tel qu’approuvé par l’arrêté du 16 septembre
2009 ;

d) L’offre du titulaire.

Article 6. ‒ Durée du marché

Le marché est d’une durée d’un an à compter de la date de notification, reconductible deux
fois pour la même période par décision expresse du pouvoir adjudicateur. Sa durée ne peut
en conséquence dépasser trois ans.

Le titulaire du marché ne peut s’opposer à la reconduction du marché décidée par le pouvoir


adjudicateur. La décision de non reconduction n’ouvre droit à aucune indemnité au profit du
titulaire.

Article 7. ‒ Délais d’exécution

Le délai de réalisation de la plateforme dans son ensemble (conception, design graphique,


développement, paramétrage) est de dix semaines à compter de la notification du marché.

Les délais d’exécution des prestations à bon de commande sont mentionnés dans chaque
bon de commande.

Article 8. ‒ Déroulement de la réalisation

4
• Organisation du projet

Le projet sera mené par un groupe restreint cumulant les fonctions de groupe projet et de
comité de pilotage et composé de représentants de l’Hadopi et du titulaire. Il se réunira au
lancement du projet et enchaînera sur un premier atelier fonctionnel. Il se réunira ensuite
selon le planning prévisionnel décidé à l'initialisation du projet.

Le titulaire propose un planning prévisionnel et l’Hadopi donne son accord ou demande une
modification de ce document. Le comité de pilotage donnera son accord final sur ce
calendrier.

Le titulaire nommera un directeur référent et un chef de projet, ils seront les interlocuteurs
privilégiés de l’Hadopi.

Les réunions téléphoniques, les maquettes électroniques, l'échange de courriers seront


privilégiés.

Un référent de la maîtrise d'ouvrage (MOA) dédié au projet sera nommé comme interlocuteur
permanent du titulaire.

Article 9. ‒ Prestations attendues

Le titulaire du marché assurera la conception technique, le développement et la maintenance


d’une plateforme internet collaborative pour les « Labs » de l’Hadopi dans les conditions
définies ci-dessous.

• Réception et admission des prestations

Les prestations sont soumises à des vérifications destinées à constater qu’elles répondent
aux stipulations contractuelles, conformément au tableau ci-dessous.
Étape Résultats attendus et livrables

1 Spécifications techniques de la solution - Dossier de spécifications détaillées


- Dossier de sécurité
- Dossier d’architecture technique

2 Ergonomie et habillage graphique des principaux - Maquettes graphiques


écrans de l’interface utilisateur (front-office) - Cinématiques de navigation

3 Réalisation, installation et paramétrage de la - Ensemble des éléments composant la solution :


solution sur un hébergement temporaire, fourni programmes sources et exécutables, contenus
par le prestataire et accessible par les agents de graphiques, bases de données, etc.
l’Hadopi - Documentation technique : dossier d’architecture
technique, manuel d’installation, manuel d’exploitation
et de paramétrage
- Accessibilité

5
- Sécurité

4 Installation du site chez le prestataire - Bilan des tests de vérification d'aptitude technique
d’hébergement retenu par l’Hadopi (VAT) passés par le titulaire sur la plateforme de
production
- Procès verbal de la VAT

5 Formation des contributeurs/testeurs - Livraison du livret de formation à destination des


administrateurs, contributeurs et rédacteurs.
- Assistance aux utilisateurs opérationnels sur la
solution.

6 Vérification d'aptitude fonctionnelle (VAF) et début - Conformité de la plateforme collaborative aux


de l’hébergement spécifications et aux besoins exprimés : cadre
fonctionnel, cadre technique et de sécurité, cadre
d’utilisation, définis par le présent cahier des charges

7 Vérification de service régulier (VSR) - Application livrée sur support électronique


- Fourniture de tous les éléments permettant une
réinstallation et prise en main ultérieure de l’application
par un tiers (codes sources, architecture technique et
composants, paramétrage…)
- Plateforme applicative opérationnelle

1/ Définition d’une architecture technique

• Objectifs

La plate-forme collaborative des Hadopi Labs doit répondre à un double objectif :

- Fédérer – autour d’un outil commun – l’ensemble des contributeurs qui participent
quotidiennement aux travaux des Labs, à la fois en interne (agents de l’Hadopi) et en
externe (plate-forme ouverte où chaque internaute peut participer). Afin de répondre
à cet objectif, la solution devra permettre :

o la gestion des utilisateurs. 5 niveaux de droits sont définis en fonction du profil de


l’utilisateur. Ces groupes peuvent évoluer et doivent être administrables ;

o l’ajout et la modification de documents dans un environnement de type Wiki ;

o la possibilité de commenter les documents publiés (approche blog).

- Organiser l’information produite ou acquise par les Labs dans un outil de type GED
(gestion électronique de documents) permettant notamment :

o l’indexation des ressources sur la base d’outils sémantiques : thésaurus,


ontologie.

o la gestion des versions pour chaque ressource publiée ;

6
o l’intégration d’un workflow de contribution et de validation des contenus.

• Axes de conception

Le soumissionnaire expose dans son offre la mise en place de l’architecture globale et


l’approche qui, en termes techniques et de communication, lui semblent les mieux adaptés
au projet de plateforme participatif décrit ci-dessus.

Le titulaire du marché devra respecter le projet défini par l’Hadopi et compléter les éléments
non prévus dans le cadre d’une démarche de conception « orientée utilisateur ».

La plateforme participative pourra prendre la forme d’un assemblage de plusieurs modules


(forum, wiki, blog, etc.) afin de construire une plateforme communautaire cohérente,
mélangeant les différents procédés en fonction de leur pertinence, de telle sorte que leur
articulation réponde précisément aux objectifs.

Le soumissionnaire assume un devoir de conseil et devra être très explicite dans les
fonctionnalités proposées.

La plateforme sera entièrement et facilement administrable par l’Hadopi.

• Préconisations fonctionnelles

La plate-forme collaborative est à la fois l’outil de gestion de contenus (fonctionnalités de


GED) - dédié à la publication de la documentation produite ou acquise par l’Hadopi - et un
outil d’échange avec les internautes qui auront la possibilité de commenter et/ou de modifier
les contenus publiés.

Concernant la partie documentaire, la solution doit être en mesure de proposer les


fonctionnalités basiques et avancées attendues dans le cadre d’un outil de gestion
électronique de documents :

- indexation de tous types de documents numériques (fichiers sonores, audiovisuels,


textes, images) à l’aide de champs de saisie modulaires. La solution doit notamment
permettre de faire évoluer le schéma de métadonnées ;

- moteur de recherche de type « full-text » et fonctionnalités de recherche avancée :


recherche par le biais d’un thésaurus ou d’une ontologie, filtres par type de
document, thématiques, tags, etc. ;

- gestion des versions et des habilitations. ;

7
- gestion du workflow de travail et de publication

Cycle de co-création d’une analyse Lab

Le terme « analyse Lab » décrit l’unité documentaire produite par les groupes de travail.
Chaque analyse est constituée :

- d’un document principal (de type texte) éditable en mode Wiki ;

- d’un ensemble de ressources associées, fichiers numériques ou références à des


publications en ligne (URL) ou papier (éléments bibliographiques) ;

- d’une zone dédiée aux commentaires, modérés avant publication.

La rédaction d’une analyse Lab suit le cycle de création décrit ci-dessous :

Fonctionnalités collaboratives et gestion des utilisateurs

La plate-forme distingue 5 niveaux de droits. Ceux-ci sont susceptibles d’évoluer, la


plateforme devra permettre une grande souplesse dans la gestion des droits et des groupes
d’utilisateurs.

8
- Visiteur : utilisateur non connecté, il dispose des seuls droits de lecture.

- Membre contributeur : utilisateur enregistré. Il a la possibilité de commenter les analyses.

- Membre rédacteur : utilisateur enregistré. Il est autorisé à modifier le contenu des analyses.

- Administrateur Lab : utilisateur ayant la possibilité d’administrer le contenu (création


d’analyses, modération des contributions) et les utilisateurs (création et attribution des droits)
de son Lab.

- Administrateur plate-forme : utilisateur ayant la possibilité d’administrer le contenu (création


d’analyses, modération des contributions) et les utilisateurs (création et attribution des droits)
de tous les Labs.

Le tableau ci-dessous décrit les fonctionnalités auxquelles les utilisateurs doivent pouvoir
accéder en fonction de leur profil.

Structure de navigation et grilles fonctionnelles

L’arborescence ci-dessous décrit l’architecture simplifiée du site et le parcours de l’utilisateur.


Ce schéma – fourni à titre indicatif – vise à donner une idée de l’ergonomie attendue dans le
cadre du projet et pourra faire l’objet d’ajustements en fonction des solutions techniques
retenues.

9
Si la solution se compose de plusieurs briques logicielles, celles-ci doivent former un
ensemble cohérent pour l’utilisateur final qui doit pouvoir naviguer de façon transparente
d’une fonctionnalité à l’autre sans changer d’environnement graphique.

2/ Développement

• Accessibilité

La plateforme devra respecter les règles définies dans le Référentiel Général d'Accessibilité
pour les Administrations (RGAA), afin d'obtenir un niveau d'accessibilité AA (Niveau WCAG).
Le référentiel et ses annexes sont accessibles sur le site :
http://www.references.modernisation.gouv.fr/rgaa-accessibilite.

• Compatibilité et interopérabilité

La plateforme devra pouvoir s'intégrer dans une infrastructure technique supportée en


standard sans surcoût par la majorité des hébergeurs. Elle privilégiera les solutions open
sources aux logiciels propriétaires.

Les informations du site devront être exploitables et affichables sans dégradation sur les
principaux navigateurs du marché (Internet Explorer, Firefox, Opera, Safari, Chrome), sur
tout navigateur réputé supporter XHTML et les CSS2, notamment sur les navigateurs des
terminaux mobiles (iPhone, iPad).

Les polices utilisées doivent être disponibles sur la plupart des systèmes d’exploitations, sauf
cas exceptionnels où le texte pourra être remplacé par une image (par exemple sur les titres)

10
de manière non-obstrusive et permettant toutefois son indexation par l’usage des attributs alt
et title.

L'application doit respecter des standards ouverts, définis par des organismes reconnus
(IETF, ISO, W3C, etc.). L'applicatif devra respecter le Référentiel Général d'Interopérabilité
(RGI), référentiel accessible sur le site : http://www.references.modernisation.gouv.fr/rgaa-
accessibilite .

Les fichiers XHTML et CSS doivent respecter les spécifications XHTML 1.0 et CSS 2 (cf.
http://www.w3.org/).

• Référencement

La page d’accueil doit permettre un référencement optimal par les moteurs de recherche
externes. Les contenus pourront être référencés directement depuis des sites externes ou
des réseaux sociaux afin de drainer un plus large public et optimiser le référencement global
du site.

Le soumissionnaire devra respecter les contraintes suivantes :

- les URL sont simples et explicites afin de garantir un bon référencement par les
moteurs de recherche ;

- le site n'utilise aucune technique destinée à masquer ou cacher l'URL de la page


visitée (pas de frames) ;

- le contenu de chaque page est organisé selon une structure de titres et sous-titres
hiérarchisée (utilisation des balises h1, h2, h3, h4, h5 et h6) ;

- chaque page comporte un titre significatif et représentatif de son contenu ;


- le code source des pages contient les informations relatives au jeu de caractères
employé : une balise meta charset permet aux robots de bien décoder les caractères
spéciaux ;
- chaque page du site contient une métadonnée qui décrit son contenu ;

- les contenus alternatifs de tous les éléments non textuels sont correctement indiqués
(par exemple le contenu alternatif au Flash, l’attribut alt de la balise img).

- l’utilisation du Javascript en général et d’Ajax en particulier (menus déroulants,


fenêtre « pop-in ») devra être compensée par une version accessible si le navigateur
n’accepte pas ce langage ;

11
- le site comprend un fichier sitemap.xml à la racine destiné à faciliter son indexation.
Ce fichier est tenu à jour par le logiciel, et un "ping" est envoyé aux moteurs lors de
sa mise à jour.

• Évolutivité

La plateforme sera développée de façon modulaire, utilisant pour la partie front-office un


système de templates de manière à ce que l’Hadopi puisse faire évoluer la charte graphique
rapidement et pour un coût restreint.

Suivant ce même principe, l’architecture de la solution devra intégrer plusieurs modules


indépendants les uns des autres, de manière à permettre le remplacement et l’ajout de
modules supplémentaires pour un coût restreint, sans remettre en cause l’ensemble de la
solution.

• Confidentialité, disponibilité, traçabilité et intégrité des données

Le soumissionnaire précise dans son offre les mesures qu’il compte mettre en œuvre pour
assurer la confidentialité, la disponibilité, la traçabilité et l’intégrité des données gérées par la
plateforme.

• Sécurité

La solution mise en place devra assurer la protection des données et réduire les risques de
rupture de la continuité de service.

Elle devra respecter les recommandations énoncées dans les documents publiés par le
CERTA à l'adresse suivante:

- http://www.certa.ssi.gouv.fr/site/CERTA-2004-INF-001/index.html
- http://www.certa.ssi.gouv.fr/site/CERTA-2007-INF-002/index.html

Elle devra en outre appliquer le Référentiel Général de Sécurité et proposer un niveau de


sécurité adéquat (http://www.references.modernisation.gouv.fr/rgs-securite).

Les événements pertinents en terme de sécurité devront être inscrits dans un fichier journal.

• Code source et binaires

L'Hadopi doit disposer de l'intégralité du code source de l'application et, le cas échéant, de
l'intégralité des éléments permettant de générer les binaires.

12
3/ Hébergement

Le prestataire n’assurera pas l’hébergement, il se doit de prendre contact avec l’hébergeur


choisi par l’Hadopi pour procéder au transfert de l’hébergement chez ce prestataire.

La responsabilité de la bonne réalisation de l’opération de transfert de l’hébergement repose


sur le titulaire du présent marché. Les vérifications qualitatives approfondies sont effectuées
par l’Hadopi dans un délai de 15 jours à compter de la date de la réalisation du transfert,
elles feront l’objet d’un procés verbal.

4/ Maintenance

• Définition des anomalies

Une anomalie correspond à un fonctionnement qui ne respecte pas les périmètres et


contenu fonctionnels ou techniques de la plateforme.

Une anomalie est dite bloquante lorsqu’elle affecte la disponibilité, la conformité, ou l'intégrité
de la plateforme et que, par exemple, elle provoque l'arrêt complet de la plateforme, rend
indisponible des fonctionnalités importantes du système ou produit un résultat erroné pour
au moins une des fonctions importantes du système.

Une anomalie est dite majeure lorsque, sans être bloquante, elle affecte la conformité,
l'intégrité ou la confidentialité de la plateforme ou des données qu'elle gère et que, par
exemple, elle restitue des données erronées, affecte l'utilisation de fonctionnalités autres
qu'ergonomique, graphique ou éditorial ou rend une fonctionnalité indisponible pour
l'utilisateur.

Une anomalie est dite mineure lorsqu’elle affecte la conformité de la plateforme dans ses
composantes mineures et que, par exemple, elle produit un fonctionnement dégradé sur des
aspects purement ergonomiques, graphiques ou éditoriaux, dits de « conforts » pour
l'utilisateur

• Maintenance corrective

La maintenance corrective a pour objet de donner à la plateforme un comportement


conforme à celui spécifié, en particulier en termes de traitements, de performances et de
mode opératoire.

Le soumissionnaire précise dans son offre les modalités de mise en œuvre de la


maintenance corrective pour les différents types d’anomalies, notamment en termes de délai
d’intervention.

13
La maintenance corrective est forfaitaire et sera chiffrée pour une durée courant du prononcé
de la VSR.

• Maintenance évolutive

Une évolution est une modification de l'application dont le but n'est pas de corriger une
anomalie.

La maintenance évolutive a pour objet la prise en compte des évolutions et leur réalisation.
Une documentation, un support de formation et la formation elle-même relatifs à cette
évolution font partie intégrante de cette dernière.

Les évolutions concernent :

- les demandes de nouvelles fonctionnalités, de modifications de fonctionnalités (en termes


techniques, de processus ou d’ergonomie),

- les adaptations. Il s’agit ici des modifications de l'application dont le but est d'adapter celle-
ci à une évolution d'un logiciel de son environnement technique ou à un changement
organisationnel : ajout de droits à un profil utilisateur, modification de la valeur d'un
paramètre statique, prise en compte d'une nouvelle version du système de gestion de base
de données de l'application, etc.

Ces évolutions feront l’objet de bons de commande.

Article 10 – Conditions d’exécution des prestations

Les prestations commencent à être exécutées après l’émission de bons de commande,


selon les besoins de la personne publique.

Les bons de commande mentionnent obligatoirement :

- le numéro et la date du bon de commande ;


- le numéro du marché ;
- la désignation précise des prestations commandées et la durée de la prestation ;
- le délai d’exécution du bon de commande ;
- les modalités particulières de paiement : en une seule fois, ou paiement échelonné
avec indication de l’échéancier de paiement ;
- le montant HT et TTC ;
- le lieu d’exécution ;
- le lieu de facturation et l’adresse d’envoi des factures.

14
Les bons de commande sont signés par le représentant du pouvoir adjudicateur ou, en cas
d’empêchement, par toute personne ayant reçu délégation de signature à cet effet.

Si la durée d’exécution figurant sur le bon de commande est supérieure à 3 mois, le bon de
commande pourra prévoir un fractionnement des paiements.

Ce fractionnement devra figurer sur le bon de commande.

Pour les prestations accessoires dont l’Hadopi aurait besoin en cours d’exécution du marché
le titulaire fait une proposition de prix et de délai de livraison sous la forme de devis.

Cette proposition fera l’objet d’une validation ou d’un rejet de la part de la personne publique.
La validation de la proposition entraîne l’émission du bon de commande correspondant,
précisant le montant des prestations, en fonction des prix indiqués dans le devis.

Article 11 – Modalités de règlement

11.1 – conditions et délais de paiement

Les prestations sont payables après certification de service fait à la livraison de chaque
livrable ou mensuellement.

Le paiement s’effectuera selon les règles de la compatibilité publique, dans les conditions
prévues à l’article 11 du CCAG/PI. Le règlement s’effectue en conséquence dans un délai
global de paiement fixé à 45 jours à compter de la réception de la facture par la personne
publique.

La personne publique se libère des sommes dues en exécution du présent marché en


faisant porter les montants au compte indiqué dans l’acte d’engagement.

10.2 – Intérêts moratoires

Le dépassement du délai de paiement ouvre droit et sans autre formalité par le titulaire du
marché, à compter du jour d’expiration du délai, au bénéfice d’intérêts moratoires.

Les intérêts moratoires ne sont pas assujettis à la taxe sur la valeur ajoutée.

Le taux des intérêts moratoires est celui de l’intérêt de la principale facilité de refinancement
appliquée par la Banque centrale européenne à son opération de refinancement principal la
plus récente effectuée avant le premier jour du calendrier du semestre de l’année civile au
cours duquel les intérêts moratoires ont commencé à courir, majoré de sept points.

15
10.3 – Facturation des prestations

Le titulaire fait parvenir à la Direction des Finances et du Développement de l’Hadopi (4 rue


du Texel 75014 Paris) chaque facture en précisant les sommes auxquelles il prétend du fait
de l’exécution du marché et en donnant tous les éléments de détermination de ces sommes.

Chaque facture est établie en un exemplaire et doit comporter, en sus des mentions légales,
les indications suivantes :

- le numéro et la date de la facture


- le nom et l’adresse du créancier
- le numéro SIRET ou SIREN du créancier, ainsi que son code APE
- le numéro et la date du marché,
- le numéro du bon de commande,
- la désignation des prestations réalisées et la durée de la prestation ;
- ou la qualification des personnes devant intervenir et le nombre de jours réalisés par
chaque intervenant ;
- le montant HT unitaire
- le montant TTC unitaire
- pour chaque taux de TVA, le montant de la TVA
- le montant total TTC, étant égal au montant total HT auquel s’ajoute le montant de
chaque taux de TVA
- le numéro de son compte bancaire ou postal.

Le comptable assignataire des paiements est l’Agent Comptable de l’Hadopi à Paris.

Article 11 – Prix – Montant

11.1 – forme et contenu des prix

Les prestations du présent marché, sont traitées à prix unitaire. Ces prix sont spécifiés dans
l’annexe financière à l’acte d’engagement, constituée du Bordereau des prix unitaires.

Les prix sont réputés :

inclure toutes les dépenses nécessaires à la parfaite exécution de la prestation, y


compris les frais généraux, impôts et taxes et assurer au titulaire une marge pour
risques et bénéfices ;

établis aux conditions économiques du mois précédent la remise des offres, mois M0

16
11.2 – Révision

Les modalités de variation des prix du marché sont les suivantes :

11.2.1 - Mois d’établissement des prix du marché


Les prix du marché sont réputés établis sur la base des conditions économiques du mois de
octobre 2010, ce mois est appelé « mois zéro ».

11.2.2 - Modalités des variations des prix


Les prix unitaires seront révisés à la date anniversaire du marché selon la formule suivante :

P = P0 x [0,15 + 0,85 (S/ S0)] dans laquelle :


P = prix révisé
P0 = prix à la date de référence du marché
S = valeur de l’indice SYNTEC au mois M correspondant à la date
anniversaire (dernier indice connu)
S0 = valeur de l’indice SYNTEC au mois M0
Les prix obtenus sont ainsi fermes pour un an.

Le mois M0 est fixé à septembre 2010.

Article 12. ‒ Pénalités

Les pénalités ci-après sont sans préjudice du droit de la Haute autorité à d’éventuels
dommages et intérêts liés au manquement du titulaire à ses obligations contractuelles.

12.1. Pénalités pour les délais contractuels

Lorsque les délais contractuels d’exécution définis par le présent cahier des clauses
particulières sont dépassés, le titulaire encourt, sauf cas de force majeure, sans mise en
demeure préalable, une pénalité d'un montant de 500 € HT par jour calendaire de retard.
Les pénalités ne s'appliquent ni en cas de force majeure et ni en cas de prolongations du
délai d'exécution accordées par l’Hadopi.

12.2. Pénalités en cas de retard pour une intervention de maintenance corrective

Lorsque les délais contractuels d’intervention fixés par le titulaire dans son offre sont
dépassés, celui-ci encourt, à partir d’un jour de retard après notification par l’Hadopi (fax,
mail ou appel téléphonique), sans mise en demeure préalable, une pénalité de :

− Anomalie bloquante : 1 000 € HT par jour de retard

17
En cas d’anomalie bloquante non résolue pendant une période de dix journées, sans que le
titulaire n’intervienne, la résiliation du marché sera prononcée par le représentant du pouvoir
adjudicateur sans mise en demeure préalable

− Anomalie majeure : 250 € HT par jour de retard


− Anomalie mineure : 100 € HT par jour de retard

Article 13 – Opérations de vérification

Les opérations de vérification ont pour objet de constater que les prestations réalisées sont
conformes à l’attente de la personne publique.

Le délai imparti à la personne publique pour procéder à ces opérations et notifier sa décision
au titulaire est de un mois à compter de la réalisation de la prestation prévue.

La validation d’aptitude fonctionnelle et la vérification du service régulier font l’objet d’un


procès verbal.

La validation d’aptitude

La validation d’aptitude dure un mois et a pour but de vérifier que le site livré est conforme
aux spécifications et aux besoins exprimés : cadre fonctionnel, cadre technique et de
sécurité, cadre d’utilisation définis dans le présent CCP.

Les critères d’achèvement sont :


− L’absence d’anomalie bloquante
− L’absence de faille de sécurité détectée
− Un nombre réduit d’anomalies majeures

Les anomalies bloquantes sont les anomalies qui affectent la disponibilité, la conformité ou
l’intégrité du site, elles :
− provoquent l’arrêt complet de plateforme,
− rendent indisponibles les fonctionnalités importantes du système,
− produisent un résultat erroné pour une des fonctions importantes du système.
Les anomalies majeures ne sont pas bloquantes et elles affectent la conformité, l’intégrité ou
la confidentialité de la plateforme. Elles :
− restituent des données erronées,
− affectent l’utilisation de fonctionnalités du site,
− produisent un résultat fonctionnel erroné,
− rendent une fonctionnalité indisponible pour l’utilisateur.
Les anomalies mineures n’entrent pas dans les deux premières catégories et affectent
uniquement la conformité du site dans ses composantes mineures. Elles :

18
− produisent un fonctionnement dégradé sur des aspects purement ergonomiques,
graphiques ou éditoriaux et n’entachent pas le bon fonctionnement d’une
fonctionnalité.

L’Hadopi peut accepter sans réserve, avec réserve, rejeter ou accepter avec une réfaction.
Lorsque la validation d’aptitude fonctionnelle est prononcée avec réserve, le titulaire
s’engage à corriger les anomalies correspondantes durant la validation de service régulier.

La vérification de service régulier

Cette étape s’assure que les problèmes qui pourraient survenir en production soient réglés
rapidement. La vérification de service régulier est prononcée dans les deux mois après la
date d’ouverture de la plateforme aux internautes.

La vérification de service régulier peut être prononcé avec et sans réserve. Le titulaire
dispose de 10 jours pour corriger les défauts.

Article 14 – Garantie

Le titulaire garantit avoir une parfaite connaissance des outils informatiques concernés par le
présent marché. Il garantit la faisabilité technique et la légalité des solutions préconisées.

Article 16 – Confidentialité

16.1 – Dispositions générales

Le titulaire reconnaît le caractère sensible de l’intégralité des informations et données


confidentielles auxquelles il aura accès et s’engage à ce titre à en préserver la confidentialité
la plus stricte.

Le titulaire veille à ce qu'au cours de l'exécution du marché, soient respectées la sécurité et


la confidentialité des données et des accès informatiques de la personne publique
conformément aux lois et régimes applicables, et notamment la loi n° 78-17 du 6 janvier
1978 relative à l'informatique, aux fichiers et aux libertés, les dispositions du Code de la
propriété intellectuelle applicables aux logiciels et celles du Code pénal. Par ailleurs, le
titulaire s’engage à veiller à ne pas conduire la personne publique à méconnaître ces
dispositions, en procédant à toutes les préconisations utiles en ce sens.

Il se porte fort du respect de cette obligation de confidentialité par ses salariés et sous-
traitants éventuels et sera responsable de plein droit en cas de manquement de l’une ou
l’autre des ces personnes.

19
De plus, le titulaire ne transmettra, les informations confidentielles, qu’aux personnes ayant
besoin d’en connaître pour la réalisation des Prestations.

A la fin du marché, le titulaire notifiera la destruction des informations confidentielles à la


Haute autorité.

L'obligation de confidentialité prendra effet à compter de la signature du présent marché et


demeurera en vigueur pour une durée de 5 ans à compter de l'expiration ou de la résiliation
de ce marché pour quelle que cause que ce soit.

Tout manquement aux présentes justifierait une résolution de plein droit du marché aux torts
du titulaire.

16.2 – Utilisation des systèmes informatiques de l’Hadopi, sécurité

Si le titulaire doit intervenir dans le cadre de la prestation dans les locaux de l’Hadopi, il
devra se conformer aux procédures de sécurité de l’Hadopi, à savoir :
− Obligation de travailler avec un poste de travail fourni par l’Hadopi, protégé
par l’antivirus de l’Hadopi et d’utiliser les identifiants fournis ;
− Interdiction de connexion de portables au réseau local, non validés par
l’Hadopi.
− Usages de la messagerie et d'internet selon les règles édictées par l’
Hadopi.

Le titulaire devra utiliser uniquement les logiciels, procédures et traitements entrant dans le
cadre de la prestation. Il ne devra pas tenter d’outrepasser les droits, permissions,
autorisations d’accès qui lui ont été donnés.

Le titulaire reconnaît avoir été avisé que les atteintes ou tentatives d’atteintes aux systèmes
de traitement automatisé de données de l’Hadopi tombent sous le coup des articles 323-1 à
323-7 du Code Pénal.

Le titulaire devra respecter vis à vis des logiciels, procédures et outils de traitements
appartenant à l’Hadopi ou dont l’Hadopi possède le droit d’usage, les lois concernant la
propriété intellectuelle.

Le titulaire se porte fort du respect des obligations prévues à cette clause par ses salariés et
sous-traitants éventuels et sera responsable de plein droit en cas de manquement de l’une
ou l’autre de ces personnes.

Article 17 – Responsabilité

20
Le titulaire indemnisera la personne publique de toutes les conséquences dommageables
liées à un manquement de sa part aux obligations prévues au présent marché et à une
mauvaise préconisation de sa part.

Le titulaire est responsable dans les conditions du droit commun des détériorations et dégâts
éventuels, causés par son personnel à l’équipement et aux autres biens de la personne
publique.

Il est également notamment responsable des dommages de toute nature causés au


personnel de la personne publique, aux biens ou aux tiers du fait :
• de son personnel en activité,
• des fournitures et des prestations réalisées par lui avant l'admission des prestations,
• d'un événement engageant la responsabilité du titulaire après l'admission des prestations.

De plus, le titulaire devra pouvoir justifier chaque année d'une assurance contractée auprès
d'une compagnie agréée, garantissant sa responsabilité civile pour dommages de toute
nature causés au personnel de la personne publique, aux biens et aux tiers.

En cas d'existence d'une franchise, dans le contrat souscrit par le titulaire, le titulaire sera
réputé la prendre intégralement à sa charge.

Article 18 – Propriété intellectuelle

Les droits sur l’ensemble des résultats et livrables qui résultent de l’exécution des
prestations objet du présent marché, notamment les spécifications fonctionnelles, dossiers,
maquettes, cinématiques, programmes, base de données, manuels, livrets, contenus
graphiques, bilans de test, sont cédés à titre exclusif, au fur et à mesure de leur création et
quel que soit leur état d'achèvement, à la personne publique.

Les droits cédés comprennent notamment:


- le droit de reproduire, sans limitation de nombre, en tout ou partie, en l’état ou
modifiés, par tous procédés et sur tous supports – y compris électroniques –, tant
actuels que futurs, connus ou inconnus ;
- le droit de représenter, de communiquer au public, de mettre à disposition du public
ou de distribuer, en tout ou partie, en l’état ou modifiés, par tous moyens, modes et
procédés – y compris électroniques –, tant actuels que futurs, connus ou inconnus ;
- le droit d’adapter, d'arranger, de corriger, de traduire, d’incorporer, en tout ou partie,
par tous moyens, tant actuels que futurs, connus ou inconnus ;
- le droit de faire héberger.

Cette cession est faite pour avoir effet en tous lieux et pendant toute la durée de la protection
légale des droits d’auteur.

21
Le prix de la cession de droits est compris de façon forfaitaire et définitive dans le montant
du marché.

Le titulaire garantit à la personne publique la jouissance paisible et exclusive des droits


cédés contre tous trouble, revendication et éviction d'un tiers, à un titre quelconque et
l’indemnisation des éventuelles conséquences dommageables pour le pouvoir adjudicateur.

Si le titulaire fournit des licences dans le cadre du marché, il garantit avoir tous droits et
autorisations nécessaires pour accorder lesdites licences et indemnisera la personne
publique contre tous trouble, revendication et éviction d'un tiers, à un titre quelconque et
contre les éventuelles conséquences préjudiciables au pouvoir adjudicateur.

Article 19 – Nantissement de créance

Le présent marché pourra faire l’objet de nantissement ou de cession de créances, l’Hadopi


fait application des dispositions présentes dans les articles 106 à 110 du Code des marchés
publics.

Article 20 – Déclarations

Conformément à l’article D.8222-5 du Code du travail, nouvelle version, le titulaire devra


fournir, tous les six mois jusqu’à la fin de l’exécution du marché, les documents suivants :

- une attestation de fourniture de déclarations sociales datant de moins de six mois (art.
D.8222-5-1°-a),

- une attestation sur l’honneur de la réalisation du travail par des salariés employés
régulièrement si le titulaire emploie des salariés (art. D.8222-5-3°),

- Une attestation sur l’honneur de dépôt auprès de l’administration fiscale, à la date de


l’attestation, de l’ensemble des déclarations fiscales obligatoires (art. D.8222-5-1°-b), ou
compte tenu du caractère annuel des déclarations fiscales, présenter la nouvelle attestation
fiscale de la situation au 31 Décembre de l’année écoulée.

En cas de non remise des documents susmentionnés par le titulaire et après mise en
demeure notifiée par écrit, restée infructueuse, le marché peut-être résilié aux torts du
titulaire sans que celui-ci puisse prétendre à indemnité et, le cas échéant, avec exécution
des prestations à ses frais et risques, lorsqu’il a contrevenu à l’article D.8222-5 du code du
travail.

Article 21 – Transfert d’activité

22
Le titulaire s’engage à informer sans délai la personne publique de tout transfert d’activité
(cession de branche commerciale, fusion, absorption, etc…) de nature à affecter l’exécution
du présent marché. La personne publique sera en droit de résilier le présent marché sur
simple préavis de 20 jours.

Article 22 – Litiges

En cas de litige résultant de l’application des clauses du présent marché, la loi française est
seule applicable.

La procédure à suivre par le titulaire en cas de différend avec le pouvoir adjudicateur est
celle exposée à l’article 37 du CCAG/PI.

Le tribunal compétent est le tribunal administratif dans le ressort duquel se situe le siège de
l’Hadopi, soit le Tribunal administratif de Paris.

Article 23 – Résiliation

La personne publique peut résilier de plein droit dans les cas et selon les modalités prévues
au chapitre VII du CCAG/PI.

Pendant la période comprise entre la décision de résiliation et la date d’effet de la résiliation,


l’exécution des prestations devra être poursuivie par le titulaire.

La personne publique se réserve le droit de demander au titulaire le remplacement du


personnel affecté au projet en en donnant les raisons.

Le refus ou l’impossibilité pour le titulaire de se soumettre à cette injonction peut entraîner la


résiliation du marché.

En outre, en application de l’article 19 du décret n°2005-1742 du 30 décembre 2005, la


résiliation du marché pourra intervenir, aux torts du titulaire, dans les conditions prévues à
l’article 29 et suivants du CCAG/PI, dans l’hypothèse où les renseignements requis à l’article
18 du décret n°2005-1742 du 30 décembre 2005 se révèleraient inexacts.

Si le titulaire du présent marché ne remplit pas ses obligations contractuelles,


l’Hadopi se réserve le droit de faire réaliser la prestation par un autre prestataire à la
charge du titulaire déficient.

Article 24 – Dérogation aux CCAG-FCS

23
Il est dérogé aux articles suivants du CCAG-FCS par le présent marché comme suit :

• l’article 12 « Pénalités » déroge à l’article 14 du CCAG-FCS.


• L’article 13 « opérations de vérification » déroge à l’article 24 du CCAG-FCS.

24