Cahier des charges PINS version 1 (CCTP)

Plateforme d'innovation numérique et sociale de
la Rive Droite
Cahier des Clauses Techniques Particulières

Émetteur GIP GPV Hauts de Garonne

Date Février 2012

12 rue du levant +336 08 40 35 49 thomas@cyneticmonkey.com @oncletom cyneticmonkey.com
CyneticMonkey 33140 Villenave d’Ornon
Page 1/46

Table des matières
Table des matières................................................................................................................2
Objet de la commande..........................................................................................................5
Le contexte............................................................................................................................7
Le GIP GPV des Hauts de Garonne................................................................................ 7
Le projet PINS.................................................................................................................. 8
Objectifs généraux........................................................................................................... 8
Description des besoins fonctionnels................................................................................. 9
Accessibilité...................................................................................................................... 9
Terminaux d’accès............................................................................................................... 10
Interface.............................................................................................................................. 10
Débit.................................................................................................................................... 11
Fonctionnalités transverses.......................................................................................... 11
Appréciation du contenu..................................................................................................... 11
Signalement du contenu...................................................................................................... 12
Export du contenu............................................................................................................... 13
Affichage dual : contenu/carte............................................................................................ 13
Filtres d’affichage................................................................................................................ 15
Vie privée............................................................................................................................. 16
Agenda............................................................................................................................ 16
Objectifs.............................................................................................................................. 16
Page d’accueil / Résultat de filtre....................................................................................... 17
Groupe d’évènements.......................................................................................................... 18
Détail d’un événement......................................................................................................... 19
Ajout d’un événement.......................................................................................................... 20
Exploration du territoire................................................................................................ 20
Objectifs.............................................................................................................................. 20
Les entités........................................................................................................................... 20
Page d’accueil / résultat de filtre........................................................................................ 22
Détail d’une ressource......................................................................................................... 22
Ajouter une ressource......................................................................................................... 24
Recherche....................................................................................................................... 24
Objectifs.............................................................................................................................. 25
Transversalité...................................................................................................................... 25
Fonctionnalités complémentaires....................................................................................... 26
Wiki collectif.................................................................................................................. 26

Page 2/46

Objectifs.............................................................................................................................. 27
Détail d’un document.......................................................................................................... 27
Petites annonces............................................................................................................ 29
Objectifs.............................................................................................................................. 30
Page d’accueil / résultat de filtres....................................................................................... 30
Détail d’une annonce........................................................................................................... 30
Projets citoyens..............................................................................................................31
Objectifs.............................................................................................................................. 31
Label projet.......................................................................................................................... 32
Les idées.............................................................................................................................. 32
Détail d’un projet................................................................................................................. 33
Webservices................................................................................................................... 34
Tableaux de bord............................................................................................................34
Administration et modération....................................................................................... 35
Description des besoins techniques..................................................................................36
API RESTful................................................................................................................... 36
Moteur de recherche......................................................................................................37
Workflow des contenus................................................................................................ 37
Datastore........................................................................................................................37
Linked Data.....................................................................................................................38
Licence logicielle............................................................................................................ 38
Distribution du code...................................................................................................... 38
Environnement technique de réalisation...........................................................................39
Langage de programmation...........................................................................................39
Standards de codage..................................................................................................... 39
Documentation...............................................................................................................40
Stockage de données.....................................................................................................40
Standards Web...............................................................................................................40
Performances Web........................................................................................................ 41
Compatibilité des navigateurs Web.............................................................................. 41
Bonnes pratiques Opquast............................................................................................ 42
Mesure d’audience......................................................................................................... 42
Extensibilité de l’application..........................................................................................42
Sécurité...........................................................................................................................43

Page 3/46

Déploiement................................................................................................................... 43
Sauvegarde et restauration........................................................................................... 43
Mise en œuvre.................................................................................................................... 43
Initialisation de l’application..........................................................................................43
Organisation du projet...................................................................................................44
Hébergement technique................................................................................................ 44
Installation et paramétrage des logiciels......................................................................45
Assistance.......................................................................................................................45
Garanties et maintenance.............................................................................................. 45
Prestations..........................................................................................................................45
Planning et itérations......................................................................................................... 46

Page 4/46

Version Auteur Date Commentaire
1.0 Thomas Parisot 13/02/2012 Version initiale

Objet de la commande
Objet de la commande : réalisation d’une plateforme d’innovation numérique et
sociale (PINS) pour le compte du GIP GPV des Hauts de Garonne.

→ http://www.rivedroitenumerique.org/

Il est demandé le développement d’une plateforme numérique destinée aux personnes
résidants sur le territoire de la Rive Droite (Bassens, Cenon, Floirac et Lormont) ; mais
également aux personnes s’y déplaçant (travail, loisirs, culture etc.).

Dans la lignée du développement économique, social et culturel de la Rive Droite, il est
désormais essentiel de fournir une plateforme servant à la fois de relais d’informations, mais
aussi de lieu d’échange et de travail pour les acteurs du territoire : particuliers, entreprises,
associations, administrations publiques ou encore les scolaires, entre autre.

La démarche entamée avec la réalisation de cette plateforme répond à 3 objectifs :

1. favoriser le rapprochement entre les différents univers d’acteurs (individus, institutions,
entreprises et associations) ;
2. favoriser l’innovation décentralisée ;
3. favoriser l’appropriation des ressources de la ville par les citadins.

Cela se traduit notamment par la concrétisation de ces actions au travers de la plateforme :

• stimulation du débat public ;
• production de connaissances ;
• développement du récit collectif ;
• production de données citoyennes ;
• faciliter les projets et la mise en relation des acteurs ;
• visualiser une carte du territoire des ressources disponibles ;
• consulter les évènements des acteurs locaux.

Page 5/46

La PINS est donc tant conçue pour apporter des informations pratiques, historiques et
évènementielles que pour mettre en commun des outils demandés régulièrement par les
usagers, et leur faciliter le travail – des fois déjà existant, comme les récits collectifs par
exemple – tout en le rendant accessible via Internet.

Dans une démarche d’ouverture, les données produites et consommées par la PINS ont
vocation à être accessibles de manière programmatique, sans mise en forme, via une API ; elle-
même consommée en interne pour les propres besoins de la plateforme.

Le marché comprend les fournitures et prestations suivantes :

• la rédaction du backlog produit à partir des documents préalablement rédigés et fournis
en annexe ;
• la conception graphique de la plateforme ;
• le développement de la plateforme ;
• les tests et recettes préalables à chaque déploiement ;
• l’assistance, l’accompagnement et la transmission des savoirs nécessaires aux
déploiements ;
• la documentation technique de la plateforme.

Page 6/46

Le contexte
Il est important de comprendre les relations entre l’acteur fédérateur de la Rive Droite, ses
relations avec les quatre communes ainsi que le procédé d’élaboration du projet PINS.

Ce projet de logiciel informatique correspond à la fois à la volonté d’un acteur territorial mais
aussi et surtout à l’expression des besoins des habitants, entreprises et associations du
territoire – l’utilisateur final.

Le GIP GPV des Hauts de Garonne
Les Grands Projets de Ville (GPV), issus de la Loi d’Orientation pour l’Aménagement et le
Développement Durable du Territoire de 1999 visent à réinsérer un ou plusieurs quartiers dans
la dynamique de développement de leur agglomération.

Ils ont succédé aux Grands Projets Urbains (GPU) mis en œuvre de 1991 à 1994. Dans la
continuité des GPU, les GPV concernent les quartiers éprouvant des difficultés liées au
chomage, à la pauvreté, à la délinquance, au problème d’image. Le programme GPV concerne
les aspects urbains, économiques et sociaux et l’amélioration des conditions de vie des
habitants.

Le Grand Projet des Villes des Hauts de Garonne est, pour les 66 000 habitants des quatre
communes : Bassens, Cenon, Floirac, Lormont, un enjeu majeur d’équilibre social et de
transformation durable des quartiers concernés.

Sur les 50 sites GPV de l’Hexagone, le GPV girondin dont la structure juridique porteuse est
un Groupement d’Intérêt Public, a la particularité d’être le seul GPV intercommunal, ce qui
souligne la dimension d’agglomération et la volonté de fédérer toutes les énergies pour
inverser les tendances qui ont longtemps stigmatisé la rive droite de la Communauté Urbaine
de Bordeaux .

Le projet de renouvellement du territoire s’appuie sur une armature originale et efficace :

• le tramway dont l’impact s’avère déterminant ;
• le parc des Coteaux, espace vert public de 400 hectares ;
• un pole de mobilité multimodal sur le bas Cenon, (gare Pont Rouge) ;
• d’importants équipements de services publics d’agglomération ;
• en attendant l’ouverture de deux nouveaux franchissements (Baccalan-Bastide et Jean-

Page 7/46

Jacques Bosc.
Ce projet s'organise autour de trois axes complémentaires :

• Le renouvellement urbain : 12 opérations représentant des milliers de logements
démolis, 5 200 logements construits, un réseau complet de médiathèques, d’écoles,
d’équipements sportifs, d’espaces publics reconstruits ou reconfigurés. En complément,
une "Charte de qualité architecturale, urbaine et paysagère" a été rédigée ;
• Le développement social : éducation et culture (création d'équipements, de festivals,
d'un projet culturel intercommunal, d'actions sur la mémoire des quartiers...) ;
• Le développement é conomique : attraction d'entreprises, activité locale, emploi,
insertion …
L'un des objectifs majeurs assignés au GPV est de changer l'image des quartiers et, au-delà, du
territoire dans son ensemble. Afin de répondre à cet objectif, le GPV s'est engagé en 2008
dans la construction d'une stratégie concertée de promotion du territoire. Cette stratégie
connaît aujourd'hui plusieurs déclinaisons numériques :

• Blog : http://www.blog-rivedroite.fr/
• Twitter : http://twitter.com/rivedroitebx
• Facebook : http://www.Facebook.com/jaime.larivedroite

Le projet PINS

Objectifs généraux

Page 8/46

Description des besoins fonctionnels
Les besoins fonctionnels de la PINS évoqués ci-après s’attachent particulièrement à
l’expérience utilisateur ressentie par ces derniers. La plateforme se veut à la fois simple d’accès
et d’utilisation sans pour autant niveler par le bas les fonctionnalités mises à disposition.

Les choix décrits sont orientés de sorte à créer le moins de barrières possibles entre
l’utilisateur final et l’application, tout en fournissant les retours d’information nécessaires aux
administrateurs de la plateforme.

Les utilisateurs, néophytes ou habitués, doivent ainsi facilement se repérer dans l’interface
graphique (lien entre le programme et l’individu) en leur apportant une information pertinente,
ainsi qu’un moyen de les inciter à devenir acteur, à un niveau d’engagement qui leur est propre.

De ce fait, la très vaste majorité des actions d’écriture est ouverte à tous, sans inscription.
Cette dernière est requise pour les cas suivants :

• souhaits de personnalisation de l’expérience de participation de l’utilisateur ;
• création de contenu à forte vocation d’animation ou de « responsabilité » (projet
citoyen) ;
• désir de concrétiser un sentiment d’appartenance à une communauté « Rive Droite ».
La présentation des besoins fonctionnels se fera en 3 temps :

1. l’accessibilité de la plateforme aux utilisateurs ;
2. les fonctionnalités transverses, à voir comme des motifs de fonctionnement ;
3. les fonctionnalités spécifiques, détaillées et illustrées dans la plupart des cas par un
prototype d’interface illustrant les mots.
La description fonctionnelle s’appuie sur le prototype d’interface fourni en annexe de ce CCTP.
Le choix mis en œuvre sera toujours celui qui correspondra le plus au prototype, allant dans le
sens de l’utilisateur.

Accessibilité
L’accessibilité de la plateforme traite de la notion au sens large : la qualité d’accès de
l’application par le plus grand nombre. Cela se traduit par une interface praticable,
compréhensible et nécessitant le minimum d’efforts cognitifs pour être utilisable.

Page 9/46

Terminaux d’accès
L’application doit être conçue pour être consultable sur une majorité de terminaux dont la liste
n’est pas bornée : ordinateurs fixes, téléphones mobiles, smartphones, tablettes, téléviseurs
etc.

Plutot que de cibler un produit fini (ordinateur X avec une résolution Y), l’application s’adaptera
à la taille de la fenêtre et aux capacités du navigateur Web appelant selon les principes de
Responsive Webdesign et de dégradation progressive.

De cette façon, sont évités les développements liés à l’entrée d’un nouvel acteur logiciel ou
matériel fournissant un accès au Web via un navigateur Web – hors correctifs spécifiques.

Interface
Les interfaces se baseront au maximum sur des fonctionnalités natives qui seront
éventuellement compensées de manière plus ou moins équivalentes sur les navigateurs
incompatibles ayant une part de marché supérieure ou égale à 10%.

De même, il ne sera pas demandé que chaque navigateur ait un affichage identique ou placé au
pixel près. En revanche, tout sera mis en œuvre pour que l’expérience de navigation soit le plus
conforme aux capacités techniques respectives aux différents navigateurs Web. L’affichage ne
doit pas porter préjudice à l’image de marque de la plateforme ou du GPV (interface « cassée »,
lente ou difficilement praticable).

L’interface utilisera les controles natifs (boutons, champs de texte etc.) du navigateur et du
système d’exploitation de chaque utilisateur. L’interaction avec ces controles pourra être
enrichie afin d’en faciliter l’usage tout en conservant une interface simple (auto-complétion,
boîtes de sélection multi-colonnes etc.).

L’utilisation d’actions déclenchées au survol d’un élément seront systématiquement
compensées pour tous les terminaux n’offrant pas de telles capacités de pointage, tablettes
tactiles notamment. Par exemple, une action normalement exécutée au survol du curseur de
souris sera effectuée par un « toucher » sur un terminal tactile (ou ne disposant pas d’un
mécanisme de pointage visuel).

Page 10/46

Débit
L’accès au contenu et aux fonctionnalités de la plateforme ne doivent pas être impactés par un
débit de bande passante faible ou aléatoire.

Autrement dit, l’action suggérée par l’affordance d’un élément d’interface doit pouvoir être
effective dès que constatée.

De même, l’affichage d’un contenu riche (cartographie du territoire par exemple) ne doit pas
bloquer le chargement des contenus situés visuellement en-dessous à l’écran. Dans cet
exemple, la carte se chargerait en parallèle des autres éléments et non au détriment des autres
objets fonctionnels affichés à l’écran.

Comme il est difficile d’estimer le débit en fonction du terminal ou d’une éventuelle
information de connexion employée, il est important de charger les éléments par ordre de
priorité d’utilisation, de visibilité et d’interaction ; via du lazy loading, du chargement
asynchrone ou de taille de viewport (pour utiliser un composant de carte adapté au mobile par
exemple).

Fonctionnalités transverses
Certaines fonctionnalités se retrouvent dans les différents modules de la plateforme. À des
fins de lisibilité, elles sont décrites dans les pages qui suivent.

Appréciation du contenu
Dans ce présent document, toute référence à un « vote » utilisateur sera caractérisé par un
vote approbatif (exemple des « +1 », « vote positif », « Like » etc.). Son but est en effet de
favoriser l’émergence de contenus par popularité, et non d’en qualifier subjectivement sa
qualité.

Page 11/46

Dans un but de partage social, l’appréciation du contenu se fera au travers de 3 plateformes
majeures : Twitter, Facebook et Google+ ; chacun de ces services proposant un mécanisme
équivalent de partage comptabilisé.

La popularité d’un contenu par rapport aux autres comme un score, en procédant à l’addition
des votes de chacune de ces plateformes – addition qui se fera de manière cyclique (tâche
cron) ou à la demande (file de traitement ou en parallèle de l’interaction utilisateur), selon la
facilité et la fiabilité de mise en œuvre technique préconisée par le titulaire.
Ainsi, un contenu ayant 5 partages Twitter, 2 « Like » Facebook et 10 +1 Google, il en
résultera un score de partage de 17.

Des plateformes de vote pourront être ajoutée ou supprimées dans le futur, par le biais d’un
développement, sans que les coûts de développement n’en soient impactant (principe du motif
de conception « adapteur »).

Signalement du contenu
La plateforme étant soumise à une grande liberté de contribution, il faut pouvoir laisser la
possibilité aux utilisateur de signaler eux-même un contenu à l’équipe d’administration du site.

Toute interaction de signalement se traduira par la saisie d’un formulaire demandant a minima
la nature du signalement (contenu offensant, spam, doublon etc.), l’identité du déclarant
(adresse email), et optionnellement, un message en explicitant les raisons.

La nature du signalement sera contextualisable en fonction de l’entité signalée. Un contenu de
type « Entreprise » aura par exemple des libellés supplémentaires comme « Entreprise fermée »,
« Informations incorrectes » etc. L’interface d’administration permettra également d’en définir
les libellés par défaut et leur ordonnancement, ainsi que les libellés spécifiques à la
contextualisation des entités de contenu.

Tout contenu signalé restera en ligne, jusqu’à ce qu’une intervention de modération soit

Page 12/46

éventuellement engagée.

Les rapports sont consignés dans l’interface d’administration et transmis par email aux
utilisateurs appartenant au groupe d’administration de la plateforme.

Export du contenu
Afin de prolonger l’ouverture de la plateforme, et dans une logique d’architecture RESTful
détaillée page 36, chaque page devrait disposer d’une ou de plusieurs représentations
exportables :

• Atom : représentation des contenus et actualités mentionnés sur la page ;
• ICS/Webcal : représentation des évènements mentionnés sur la page ;
• KML : représentation des lieux géographiques mentionnés sur la page (et affichés sur la
carte).
Cet export permet à la fois aux utilisateurs de récupérer les contenus via leur terminal
d’utilisation mais aussi de pouvoir l’utiliser dans d’autres contextes (sites Web d’associations,
autres annuaires ou agenda de quartier etc.).

Affichage dual : contenu/carte
Suite aux ateliers de co-conception, il a été relevé que les informations textuelles étaient aussi
importantes que la représentation du territoire. Un utilisateur peut autant être amené à
s’informer via les informations textuelles que par les informations géographiques, d’un point
choisi arbitrairement (son domicile, son lieu de travail etc.).

Page 13/46

Une carte interactive (type Google Maps ou API Cub), compatible et performante sur des
terminaux mobiles, sera donc systématiquement présente sur chaque page du site. Elle
affichera sous forme de marqueurs tous les lieux géolocalisés présents dans les contenus
(textes, images, vidéos etc.).

Chaque marqueur, après avoir été sélectionné par une action volontaire de l’utilisateur (clic,
toucher etc.), affiche une infobulle résumant les informations du contenu en fonction de son
entité (entreprise, événement, page de récit collectif, etc.). L’infobulle présente un lien
emmenant vers la page dédiée à ce contenu.

La carte présente des controles simples :

• minimiser : réduit la hauteur de la carte si celle-ci est maximisée, sinon inactif ; dans cet
état, la carte occupe au maximum 25% de la carte, dans une limite de 300px ;
• maximiser : agrandit la hauteur de la carte pour occuper tout l’espace vertical présent
dans la fenêtre du navigateur tout en affichant des controles de recherche
supplémentaires ; devient inactif si la fenêtre est déjà maximisée ;
• explorer : correspond à un raccourci menant au module « Explorer » ;
• + / ajouter un lieu : controle déclenchant l’ajout d’un contenu géographique (prodédure
détaillée dans le prototype visuel).
Sur des terminaux à écran de petite taille (de type smartphone), la carte n’est pas affichée par
défaut, et les controles « minimiser » et « maximiser » sont remplacés par un controle alternatif
de type « on/off », affichant ou masquant la carte.

En mode d’affichage maximisé, un controle de recherche s’ajoute à l’affichage. Ce controle
comprend un champ de texte permettant de rechercher dans les contenus géolocalisés, ainsi
que d’un filtre sur les types de contenus géolocalisables recherchés. L’action de recherche met
ensuite à jour la carte avec les marqueurs correspondants.

Par défaut, la carte est centrée sur des coordonnées médianes à tous les points affichés, à un
niveau de zoom permettant de tous les représenter sur la taille en cours de la carte. En cas de
trop forte densité de points, un cluster, est affiché, mentionnant le nombre de points
regroupés sous sa houlette. Ce cluster est ensuite dissout en fonction du niveau de zoom, et
toujours, de densité de marqueurs.

« Mon emplacement géographique »
Chaque module peut permettre à l’utilisateur d’orienter le tri/affichage textuel de données par
rapport à son emplacement géographique. Si tel est le cas, lors de l’activation de la

Page 14/46

fonctionnalité (exemple : une case à cocher), le navigateur détecte la position à partir d’une API
standard (HTML5 Geolocation pour ne pas la nommer).

Une fois la position détectée, un nouveau marqueur apparaît sur la carte à ce dit-emplacement.
La carte s’ajuste de sorte à afficher ce marqueur : si l’utilisateur a déjà personnalisé le niveau
de zoom, elle se recentre, sinon elle peut aller jusqu’à zoomer/dézoomer de sorte à ce que la
zone affichée couvre ET les marqueurs ET la position de l’utilisateur.

Ce marquer de position peut être déplacé par l’utilisateur, de sorte à rectifier l’emplacement,
ou tout simplement pour facilement se projeter sur un lieu différent (domicile, etc.).

Filtres d’affichage
L’affichage au sein de l’interface suit la logique de l’entonnoir : du plus important au plus
détaillé. Les filtres d’affichage sont là pour aider à accéder aux thématiques de contenus
pertinentes pour l’utilisateur.

Ces filtres sont définis par module, et correspondent à des filtres dits de « consommation ».
Un filtre « sport », peut par exemple regrouper des contenus tagués comme « judo »,
« escrime » et « basket ».

Une option permettra d’organiser les résultats en priorité par rapport à son emplacement
géographique, déterminé en priorité par rapport à la position renvoyée par le navigateur, sinon
par une demande adressée à l’utilisateur : centre de la carte (si affichée), ou une adresse
postale saisie par l’utilisateur (ou issue de son profil utilisateur).

L’interface d’administration permet de créer ces filtres de consommation, et d’y associer un ou
plusieurs mots-clés de contenu.

Dans un deuxième temps, un clic sur un de ces filtres de consommation permettra de
sélectionner plus finement chaque thématique (cf. prototype visuel). La sélection de
l’utilisateur sera mémorisée en session, par module ; et dans ses préférences de compte s’il est
authentifié, pour retrouver sa sélection la session suivante.

Page 15/46

Vie privée

Par défaut, tous les contenus créés sur la plateforme sont publics. Toutefois, dans les
contextes d’organisation, un contenu peut voir sa portée limitée aux adhérents d’une entité
(entreprise, association, événement, projet citoyen etc.).

Ces contenus à portée limitée n’apparaissent donc que pour les personnes identifiées, vérifiant
les conditions d’appartenance à au moins une des entités sélectionnées. Ces contenus sont
signalés par une iconographie suggérant la portée restreinte du contenu.

Un individu créant un contenu ne peut en revanche restreindre la visibilité qu’à des entités dont
il fait lui-même partie.

Agenda
L’agenda est le module permettant de consulter, de créer et de participer à des évènements
organisés sur le territoire.

Chaque page du module agenda affiche les filtres de recherche, ainsi qu’un controle incitant à
créer un nouvel événement.

Objectifs
• Permettre un accès aux évènements autour de soi (géolocalisation)

Page 16/46

• Permettre un accès aux évènements de tout type

Page d’accueil / Résultat de filtre
Cette page a pour but d’afficher un panorama synthétique et guidé pour l’utilisateur. Il se
compose de plusieurs parties distinctes, par ordre décroissant d’importance :

• Un événement à la une ;
• Les prochains évènements, jour par jour ;
• Des coups de projecteurs vers des groupes d’évènements ;
• Les évènements populaires.

Évènement à la une
L’évènement à la une est un événement sélectionné par un administrateur de la plateforme
dans un but d’animation éditoriale. Illustré par une vignette, le titre de l’évènement est
accompagné de ses dates et durées, le nombre de lieux concernés ainsi qu’un chapo descriptif.

Prochains évènements
Les prochains évènements sont affichés sur la période des 7 prochains jours (information
paramétrable). Ils comportent, jour par jour, les évènements publics et auxquels l’utilisateur est
autorisé à voir. Chaque événement est représenté par sa vignette, ou à défaut la vignette de sa
thématique (du filtre de consommation).

Au survol d’un pointeur ou au toucher d’une interface tactile, la vignette révèle des
informations importantes telles que ses horaires et/ou sa durée ainsi qu’un controle d’action de
géolocalisation sur la carte.

Page 17/46

Coups de projecteur
Les coups de projecteurs correspondent à la mise en valeur d’évènements phares au sein d’un
groupe (voir « Groupe d’évènements », page 18). L’administrateur de la plateforme détermine
via une interface d’administration quels sont les groupes à mettre en avant, leur ordre
d’affichage, ainsi qu’un ou plusieurs de leurs évènements.

L’objectif n’est donc pas de mettre en avant tous les évènements d’un groupe, mais seulement
une sélection, affichée par ordre chronologique.

Évènements populaires
Les évènements populaires correspondent à une liste décroissante des évènements ayant
recueilli le plus de votes sur les 20 derniers jours (information paramétrable). En cas d’égalité,
le nombre total de votes aide à déterminer la popularité.

Une dizaine d’évènements est affichée ; ce nombre étant paramétrable par un administrateur.

L’affichage reste simple, avec la date de début, la date de fin ainsi que le titre de l’évènement.

Groupe d’évènements
Les groupes d’évènements permettent une éditorialisation plus poussée. Un groupe lie entre
eux différents évènements, d’une même manifestation ou d’un même ensemble thématique par
exemple.

Page 18/46

La page détaillant un groupe comporte les éléments suivants :

• date de début des évènements (date de début la plus ancienne de tous ses
évènements) ;
• de de fin des évènements (date de fin la plus récente de tous ses évènements) ;
• description détaillée via un éditeur de texte riche ;
• un tableau listant les évènements, avec mise en valeur de ceux sélectionnés comme
« coup de projecteur » ;
• une liste des entités organisatrices et des ressources associées (projets citoyens, récit
collectif).
Ces mêmes administrateurs choisissent également si ce groupe est à placer en « coup de
projecteur », et si oui, lesquels de ses évènements sont mis en avant.

Détail d’un événement
Cette page a un double objectif :

• fournir les informations nécessaires à la compréhension et à l’appréciation de
l’évènement ;
• engager l’utilisateur à le rejoindre s’il est intéressé.
Un événement véhicule les informations suivantes auprès du public :

• Nom ;
• Date de début ;
• Heure de début ;
• Date de fin ;
• Heure de fin ;
• Une présentation riche (texte mis en forme, images et/ou vidéos) ;
• Un ou plusieurs organisateurs avec un lien vers leur entité respective (association,
entreprise etc.).
Tout individu, connecté ou non au site, peut exporter les informations (iCal, RSS), les
transmettre à des contacts de son choix, partager la page via un réseau social ou encore
signaler un problème.

Des évènements similaires sont affichés en marge, en se basant sur des thématiques
communes.

Les évènements connexes, quant à eux, se basent sur un affichage d’évènements au sein d’un
même groupe d’évènements : groupe d’évènements, entités organisatrices ou combinaison
emplacement géographique/date.

Page 19/46

Les évènements populaires ont déjà été décrits en page 18.

Ajout d’un événement
L’ajout d’un nouvel événement peut se réaliser à 3 niveaux, cumulables :

1. manuellement, par tout individu navigant sur l’application, sans obligation d’inscription ;
2. automatiquement, en enregistrant l’adresse d’un flux RSS/iCal dans les informations
relatives à une entité que l’on administre (entreprise, association etc.) ;
3. automatiquement, de manière globale, par un administrateur de la plateforme ayant
renseigné une ou plusieurs adresses de flux RSS/iCal dans l’espace d’administration.

Exploration du territoire
Le role de l’exploration du territoire est de dépasser le simple cadre de l’annuaire d’adresses. Il
s’agit bel et bien de trouver les différents types de ressources géolocalisées : entreprises,
associations, installations sportives, arbres remarquables, bornes de taxi, arrêts de bus etc.

Toujours dans la logique PINS et GPV, toute personne navigant sur l’application peut y
contribuer en ajoutant de nouvelles ressources. Chaque ressource correspond à une entité, à
savoir, un type de contenu avec des attributs partagés mais aussi spécifiques.

Objectifs
• Être un annuaire visuel du territoire
• Améliorer la lisibilité du territoire
• Mettre en valeur les spécificités de chaque entité (entreprise, association etc.)
• Mettre en valeur les besoins/demandes des entités

Les entités

Les entités sont des types d’emplacement géographique représentant une structure de
données particulière. On en dénombrera un certain nombre à la première mise en ligne du
projet :

• Association ;
• Point d’intérêt ;
• Entreprise ;

Page 20/46

• Commerce ;
• Espace vert ;
• Bâtiment scolaire ;
• Santé ;
• Service public.
Chacune de ces entités (ainsi que les futures) comportent des caractéristiques communes :

• Un nom ;
• Une description textuelle riche ;
• Une ou plusieurs adresses postales (et les coordonnées GPS associées) ;
• Thématique et/ou sous-thématique.
Elles embarquent ensuite des données spécifiques à leur représentation, par exemple et de
manière non exhaustive :

• Association
◦ Description ;
◦ URL du site Web ;
◦ Adresse email de contact ;
◦ Numéro de téléphone.
• Commerce
◦ Description ;
◦ Numéro de téléphone ;
◦ Horaires d’ouverture ;
◦ Lieu accessible aux fauteuils roulants ;
◦ Labels et certifications (éco-défis, artisan de France etc.) ;
◦ Profil foursquare ;
◦ Profil dismoioù.
• Entreprise
◦ Description ;
◦ Numéro de téléphone ;
◦ Recrutements possibles (stage, CDD, CDI etc.) ;
◦ Labels et certifications (éco-défis, ISO 9000 etc.).
Ces listes seront à définir pendant le projet, afin de définir les différents types d’attributs
possibles ainsi que les critères de validation (dans quelles condition la saisie d’un utilisateur
satisfait ou ne satisfait les attentes de la plateforme).

Page 21/46

Certaines entités peuvent avoir une capacité d’organisation (typiquement, une association, une
entreprise ou un commerce, mais pas un arbre remarquable). Chaque lieu de ce type peuvent se
voir « réclamer » la paternité par une personne faisant partie de cette organisation.

Une fois la paternité accordée par un administrateur de la plateforme, l’utilisateur en question
peut modifier à loisir les informations de la ressource.

Page d’accueil / résultat de filtre

La page d’affichage de liste présente un aperçu de n-résultats par thématique d’exploration. La
priorité d’affichage, et le nombre de résultats par page de thématique, sera déterminé par les
administrateurs de la plateforme.

L’utilisateur aura loisir d’afficher la suite des résultats pour les thématiques de son choix, si
possible (c’est à dire, s’il y a encore des résultats à afficher – concept de pagination non-
numérotée).

Par défaut, on envisage de lister les résultats par popularité (nombre de votes utilisateur), puis
par ordre alphabétique. Si l’utilisateur exprime un souhait d’affichage par proximité
géographique, la distance devient alors le seul critère de tri.

Détail d’une ressource

Le détail d’une ressource répond à plusieurs objectifs :

• fournir les informations sur les fonctions et les accès à ce lieu ;
• fournir les moyens nécessaires au suivi des activités de l’entreprise, via l’affichage
d’évènements, des flux RSS ou encore de notifications.

Page 22/46

Un premier emplacement résumera l’essentiel des informations à connaître :

• Nom du lieu ;
• Description ;
• Liens d’action rapide :
◦ Accès aux informations pratiques
◦ Accès à la liste des prochains évènements ;
◦ Réclamation de la propriété du lieu ;
◦ Signalement d’un problème ;
◦ Export / téléchargement du contenu (KML, GeoRSS, iCal) ;
◦ Nombre de membres, et adhésion ;
• Vote utilisateur.
Deux autres zones viennent compléter ces informations en présentant :

• Une liste imagée des certifications renseignées (éco-défis, charte anti-discrimination
etc.) ;
• Liens de présence externe sur le Web (site Web, foursquare etc.).
S’ensuit alors une zone large présentant les différents médias associés, d’une hauteur fixe
mais paginable. Une interaction avec l’un des médias lance soit une visualisation vidéo, un
agrandissement d’image ou la lecture audio de la ressource associée.

Tout utilisateur peut contribuer en ajoutant un media par le biais d’une URL :

1. l’application détecte s’il s’agit d’un contenu de type média ;
2. si ce n’est pas un format accepté, et qu’il s’agit d’un contenu HTML (par exemple l’URL
d’une vidéo YouTube ou Instagram), l’application détecte la présence d’un contenu
oEmbed ou d’une balise OpenGraph (type og:image ou og:video).
L’upload (ou téléversement) de médias n’est pas prévu, pour l’instant.

Sont également présentés les éléments suivants :

• Informations pratiques (listes d’adresses, téléphone etc.) ;
• La liste des prochains évènements organisés par cette entité ;

Page 23/46

• Les éventuels projets locaux auxquels participe l’entité.

Ajouter une ressource

À la manière d’un événement d’agenda, l’ajout d’un point se passe de la manière suivante :

• placement de l’utilisateur du marqueur sur la carte
• proposition alternative de saisie de l’adresse postale ;
• saisie repositionnant le marqueur à l’endroit désiré ;
• confirmation de l’utilisateur, modifications ou annulation ;
• sélection du type d’entité ;
• complétion du formulaire spécifique à l’entité en question.

La création d’un lieu pouvant se réaliser sans être membre de la plateforme, le souhait est de
bloquer le moins possible l’utilisateur en lui proposant en fin de « tunnel » :

• la possibilité de se connecté s’il n’est pas identifié ;
• la possibilité de saisir un pseudonyme ainsi qu’une adresse email.

Si l’utilisateur est déjà identifié, cet aspect ne lui est même pas proposé.

Globalement, cette définition se rapproche fortement de ServiceLab –
http://www.servicelab.fr/. Ce service a d’ailleurs vu le jour suite aux ateliers collectifs animés
durant la gestation du projet.

Recherche
Effectuer une action de recherche est une chose communément utilisée dans l’utilisation
quotidienne d’Internet. La popularité de Google s’est entre autre affirmée par le sentiment de
pertinence de recherche de la part des utilisateurs du service.

L’hétérogénéité des contenus à disposition ainsi que le contexte de recherche permanente
d’information de la part des usagers de la plateforme oblige à fournir à la fois un outil de
recherche performant et intuitif.

Page 24/46

Objectifs
• Permettre une navigation transverse par mots-clés ;
• Permettre d'atteindre un contenu pertinent en se basant sur une expression de
recherche ;
• Rechercher dans tous les contenus possibles au sein d'une seule interface ;
• Naviguer au sein de cette même recherche par systèmes de filtres ;

Transversalité
En requêtant par le biais d’une expression de recherche, l’utilisateur ne connaît pas l’étendue
des résultats possibles. C’est à la plateforme de lui retourner ce qu’il attend, mais également
de lui ouvrir son champ de possibles.

La recherche d’une expression doit aller sonder tous les contenus publiés sur la plateforme,
segmenter leur module d’appartenance et effectuer un tri sur un score paramétrable,
mélangeant date, popularité du contenu, pertinence de l’expression face au contenu (est-ce
l’expression entière qu’on y retrouve, ou juste une partie ?) voire l’emplacement géographique.

Ainsi, un utilisateur cherchant « judo » doit pouvoir obtenir des informations sur les lieux
proposant du judo, les associations sportives où se pratiquent le judo, des évènements sportifs
organisés sur le territoire ou encore une exposition sur les arts martiaux.

De la sorte, l’utilisateur est à même de découvrir des lieux jusque là insoupçonnés, d’y avoir
accès et de profiter ainsi de l’activité du territoire.

Page 25/46

Fonctionnalités complémentaires
Le moteur de recherche pourrait également être l’outil fournissant des fonctionnalités à
l’ensemble de l’application :

• contenus connexes : que ça soit d’un même type ou non, sur un ensemble de mots-
clés similaires par exemple – agirait comme des suggestions de contenus similaires,
et/ou d’autres contenus sur le même thème ;
• facettes : les facettes offrent des chemins de navigation transverses, où, à partir d’un
lien, on peut accéder à des contenus les partageant, dans le même module ou
l’application entière (ressemble aux contenus connexes sauf qu’on fournit un moyen d’y
accéder, et non un affichage au sein d’une page) ;
• sélection des contenus : obtenir les évènements récents ou une liste de contenus
populaires peut revenir à développer des requêtes en base de données similaires à ce
que ferait le moteur de recherche. Cela pourrait être une piste sérieuse à considérer
pour des gains de temps, tout en conservant une homogénéité d’accès aux informations
dans l’aspect développement logiciel.

Il n’est pas demandé de développer une solution de recherche sur mesure, mais
plutot d’adapter des logiciels déjà existants (type ElasticSearch ou Solr) et de les interfacer
avec l’application. Ces logiciels sont déjà éprouvés, et fournissent toutes les fonctionnalités
requises.

Wiki collectif
Le wiki collectif est issu d’un besoin fort émanant des habitants de la Rive Droite. On
dénombre pas moins de 150 initiatives locales de récit collectif, ayant pour but de documenter
l’Histoire du territoire, tant au passé que dans le présent.

D’autres initiatives pourraient voir le jour si elles avaient à disposition un outil simple,
participatif et à faible barrière technique d’entrée. Autrement dit, un outil permettant de saisir
facilement et rapidement, du texte et des médias hétérogènes.

On pourrait le résumer en outil webdocumentaire sur le territoire, ouvert et contributif. Les
usages seraient à la fois informatifs et pédagogiques.

Page 26/46

Objectifs
• Permettre la contribution de textes, images et vidéos ;
• Valoriser le travail des associations ;
• Faciliter le devoir/travail de mémoire ;
• Documenter le territoire ;
• Découvrir le territoire par lieu ou par date.


La page d’accueil a pour but de refléter le dynamisme de contribution ainsi que la diversité des
contenus existants. La démarche étant pour le moins originale, on souhaite également informer
l’internaute de passage de la démarche.

Afin de faciliter l’accès à l’information et à susciter la curiosité, on souhaite s’orienter vers
différents points d’entrée :

• via l’œil, via une galerie de médias fonctionnant sur le même principe que pour
l’exploration du territoire (voir page 22) ;
• via les entrées populaires de thématiques choisies ;
• via les thématiques elles-même ;
• via une chronologie de contenus, dans le temps historique.

En résultat de filtre, on souhaite procéder de la même manière, en restreignant les contenus à
la thématique de navigation indiquée par l’utilisateur.

Ce dernier a ainsi le loisir de naviguer dans du contenu récent, apprécié par les utilisateurs ou à
une époque donnée.

Détail d’un document

Un document contribué n’a pas de structure définie, en terme de rédaction. En revanche tous
les contenus partagent des attributs communs :

• Un titre ;
• Un corps, contribuable via un éditeur de texte enrichi, découpé en sections ;
• Des mots-clés ;
• Et des métadonnées :

Page 27/46

◦ Des coordonnées GPS (plusieurs possibles) ;
◦ Des dates (années, dates précises) ;
◦ Des liens vers une ou plusieurs autres entités (du wiki ou de la plateforme) ;
◦ URL source.
Chaque section du corps peut être commentée, de sorte à recueillir des réactions sous forme
de conversations, avec une granularité plus précise.

La contribution s’effectue d’ailleurs à même le détail du document : que ça soit le corps de
texte ou l’ajout d’un commentaire.

Page 28/46

À la manière d’un wiki, le module de récit collectif devra proposer une gestion des révisions :
pour revenir dans le temps (en cas de mauvaise manipulation), gérer d’éventuel conflit de
rédaction etc. Ainsi, plusieurs contributeurs peuvent œuvrer sur un même contenu sans que ça
ne pose de problème.

En parallèle de la phase de conception de cette plateforme, un outil répondant exactement aux
fonctionnalités souhaitées a été découvert : Substance (http://substance.io). Là encore, le
prestataire aura à justifier le développement d’un outil sur mesure plutot que de se baser sur
des solutions existantes, qu’elle soit celle citée ci-avant, ou une autre fournissant des
fonctionnalités similaires.

Petites annonces
Toujours au cours des ateliers de conception de la plateforme, les habitants ont fait état du
souhait de pouvoir plus facilement se mettre en relation entre eux pour des services, gratuits.

Ainsi, ce module de petites annonces est à vocation non-commerciale, tant dans l’usage (un
utilisateur ne paie pas pour placer une annonce) que dans l’obtention du service (l’utilisateur ne
paie pas, directement ou indirectement, le service fourni par l’annonce).

Page 29/46

Les thématiques des annonces seront administrées et ce, dans la volonté d’orienter les
annonces qui seront déposées : dons de matériel, échanges de services etc.

Objectifs
• Faciliter la mise en relation des habitants ;
• Fournir un service gratuit de bout en bout.

Page d’accueil / résultat de filtres

Ce type de page reflète les informations nécessaires à une prise de connaissance rapide des
offres à disposition :

• Pour les demandes :
◦ Demandes dont une échéance approcherait ;
◦ Demandes populaires ;
• Pour les offres :
◦ Offres se terminant bientot ;
◦ Offres populaires ;
• Thématiques contenant des annonces : leur nombre sera affiché dès lors que les
gestionnaires estimeront avoir une masse critique suffisante.

La possibilité de trouver des annonces de manière géographique soutient fortement la volonté
de fournir un service gratuit de proximité hyperlocal.

Détail d’une annonce

Le détail d’une annonce doit répondre à un double objectif :

• Prendre connaissance de la teneur de l’offre ;
• Permettre une prise de contact rapide avec le dépositaire de l’annonce.

Les informations affichées sont les suivantes :

• Titre ;
• Type (offre ou recherche) ;
• Description (contenu riche) ;
• Échéance (30 jours maximum par défaut, configurable par les administrateurs) ;
• Lieu (facultatif)
◦ Point sur la carte ;

Page 30/46

◦ Rayon d’action (optionnel) ;
• Entité liée (facultatif) : entreprise, association, projet etc.

La personne intéressée formulera sa demande via un formulaire de contact adapté, transmis
par la plateforme au dépositaire. Libre aux deux personnes de s’arranger entre elles, en dehors
de la plateforme.

Un mécanisme de commentaires permet également de poser des questions de manière
publique. Les commentaires s’affichent à la suite de l’annonce.

Le dépositaire d’une annonce peut indiquer qu’elle a été pourvue afin de la retirer des listings,
avant la fin de l’échéance.

À terme, est envisagée la possibilité d’agréger des flux d’informations, afin de créer
automatiquement des annonces depuis des plateformes externes. Ça ne fait toutefois pas
l’objet de ce marché.

Projets citoyens
Ultime élément envisagé pour faciliter la mise en relation et le travail des amateurs de la Rive
Droite, les projets citoyens sont un module adapté à la gestion de projets locaux :
organisation d’un événement, travail sur une problématique, organisation d’actions collectives
(par exemple, un pédibus) mais aussi un moyen pour les acteurs de la Rive Droite de fédérer
des utilisateurs autour de leur cause : biennale panOramas, kermesse de fin d’année etc.

Ce module est un outil de travail, de rassemblement et d’organisation.

Objectifs
• Faire émerger de nouvelles idées ;
• Valorisation des actions sur le territoire ;
• Créer et favoriser le lien social.

La page d’accueil fournit un ensemble d’informations couvrant l’activité des projets au sein de

Page 31/46

la plateforme. Elle est soumise à une forte éditorialisation pour leur mise en valeur. Cela se
traduit par différents axes de présentation.

Tout d’abord, un projet est mis en avant dans un encart. Il est illustré d’une miniature, de sa
description ainsi que du nombre de participants à sa réalisation.

Une sélection de labels projet s’ensuit, afin de présenter des axes transversaux de projets,
illustrés par une icone.

Quelques thématiques de projets populaires affichent jusqu’à 5 projet populaire pour chacune
d’entre elles.

En marge, les coups de projecteur présentent des projets à valoriser, un peu à la manière du
projet en une : un titre suivi d’une brève description, quelques mots-clés ainsi que le nombre
de participants.

Deux autres encarts présentent une liste de nouvelles idées (voir « Proposer une idée » page
32) puis les prochains évènements liés à des projets (éléments créés dans le module
« Agenda » organisés par une entité de type « projet »).

Label projet
Les labels projet sont un moyen de promouvoir des projets non par leur popularité mais pour
une cause : développement durable, soutien par la Rive Droite etc.

Un label projet est illustré par une icone, une description riche visant à présenter son action
ainsi qu’une liste exhaustive des projets actifs en bénéficiant.

Les idées
Une « idée » est un concept intermédiaire entre « rien » et un projet. Des individus peuvent

Page 32/46

avoir des idées mais pas le temps ni l’envie de mener un projet à bien. Ce concept facilite la
participation de tout un chacun en proposant quelque chose pouvant être mis en œuvre par la
communauté des utilisateurs de la plateforme.

Une idée se résume à peu de choses :

• Un titre ;
• Une description riche.
Les utilisateurs peuvent ensuite voter pour une idée, la commenter, voir la liste de projets
l’ayant utilisée comme base de départ ou également, créer un nouveau projet à partir de cette
idée.

Une fois une idée transformée, elle reste en ligne dans la mesure où elle peut donner naissance
à plusieurs projets, chacun ayant une vision ou des buts différents.

Détail d’un projet

Un projet constitue un élément central dans l’organisation de l’information et d’actions entre
différents utilisateurs :

• Nom ;
• Description riche ;
• Objectifs ;
• Illustration ;
• Entité(s) organisatrice(s) ;
• Fonctionnalités de base :
◦ Conversations (commentaires successifs à un sujet initial) ;
◦ Évènements ;
◦ Petites annonces ;
◦ Documentation / Wiki ;
• Activité (liste des interventions sur les éléments précédemment cités).

Cela revient à réutiliser toutes les fonctionnalités de la plateforme, autour d’un élément : le
projet. Et d’accéder de la même façon à son activité.

Par ailleurs, chacun des évènements, document, annonces et conversations d’un projet peut
disposer d’une visibilité semi-privée : dans ce cas précis, le contenu n’est accessible qu’aux
personnes adhérentes au projet.

Page 33/46

Contrairement aux autres fonctionnalités de la plateforme, l’inscription est obligatoire pour
créer un projet (pas une idée).

Par la suite, d’autres fonctionnalités seront rajoutées, car demandant des développements
supplémentaires :

• Gestion des groupes d’utilisateurs ;
• Annonces publiques ;
• Doodle ;
En cas d’inactivité (90 jours par défaut, paramétrable par un administrateur), un projet peut
être basculé dans un « bac à sable » par un administrateur, dûment notifié.

Webservices
Les Webservices sont une base constitutive essentielle de la plateforme. Elle en consommera
tout autant qu’elle en produira, pour ses propres usages mais également à des fins d’export,
pour les utilisateurs et d’autres services souhaitant se baser sur les données de la plateforme.

Chaque module produira par défaut ces types de flux de données :

• iCal dès lors qu’il y a des données calendaires ;
• RSS/GeoRSS dès lors qu’il y a des contenus chronologiques et/ou géographiques ;
• KML dès lors qu’il y a des contenus géolocalisés.

Ces formats populaires facilitent la réutilisation de données, tant par les utilisateurs via des
applications que par des machines, peu importe l’objectif sous-jascent.
L’application consommera elle-même ces données, pour alimenter la carte du territoire :
chaque contenu géolocalisé affiché textuellement devant se retrouver affiché sur la carte.

Chaque information affichée sur la page pourra faire l’objet d’un Webservice (liste des derniers
projets, évènements connexes etc.). Il faut donc qu’elle soit suffisamment flexible pour
exporter des contenus structurés sans lourdeur.

Tableaux de bord
Afin de piloter aisément la plateforme, des tableaux de bord praticables devront être mis en

Page 34/46

place. Ces tableaux de bord ont pour but de comprendre l’activité au sein des contenus, et
d’aider à la gouvernance et à son éditorialisation.

Ainsi, chaque module doit se voir doté d’un tableau apportant au moins ces informations :

• contenus inactifs ;
• nouveaux contenus ou récemment modifiés ;
• contenus populaires par vote/nombre de commentaires/RSVP/modifications ;
• les contributeurs actifs.

Chacune de ces métriques servira à mesurer la bonne santé de l’application et permettra
d’accéder facilement à la visualisation du contenu associé, pour controle.

Ces tableaux pourront être navigables :

• temporellement (entre une date X et une date Y par exemple) ;
• pour un utilisateur/adresse email/adresse IP donnée ;
• pour une entité donnée ;
• depuis sa dernière connexion (en tant qu’administrateur – raccourci temporel).
Ces tableaux n’utiliseront pas de technologie Flash pour l’affichage, mais des technologies
standards (type SVG).

Administration et modération
Par défaut, la modération des contenus s’effectue a posteriori. D’où l’importance des tableaux
de bord pour se tenir informé du mouvement des contenus.

Chaque module se verra également doté d’un panneau de paramétrage compréhensif, destiné à
affiner/régler des détails de configuration sans recourir à des développements
supplémentaires après livraison. Ces réglages permettent notamment de déterminer le nombre
maximal d’items (dans les listes, en contenus connexes) ou des valeurs par défaut.

De même, chaque module est doté d’un panneau à vocation éditoriale. Ce panneau permet aux
gestionnaires de la plateforme de choisir à volonté quels contenus seront mis en avant, et de
quelle manière (à la une, en groupement latéral ou autre, selon le module).

Page 35/46

Enfin, un panneau d’alertes permet de suivre l’activité de chaque module, en fonction des types
d’activité : nouveau commentaire, modification, nouveau contenu, nouvelle RSVP, nouveau
vote, nouvelle remontée d’alerte etc.
Dans ce dernier cas, l’équipe de modération est également notifiée par email, afin de pouvoir
réagir rapidement. Toutes les personnes chargées de la modération reçoivent alors un email
vers le lien d’administration, pour agir. Ces personnes peuvent se répondre entre elles, via
email, car elles sont toutes en copies visibles.

Description des besoins techniques
Cette partie explicite davantage les attendus techniques de la plateforme. Les choix techniques
sont en effet cruciaux pour conserver de bons espoirs de bénéficier d’une plateforme
fonctionnelle et durable dans le temps.

API RESTful
Dans la mesure du possible, chaque contenu visible du site correspondra en réalité à une
représentation HTML d’un ensemble de données, pouvant dès lors être obtenues dans des
formats différents (type RSS ou KML) dès lors que le client faisant appel à ces informations le
spécifie (via l’entête Accept).

Cette API sera manipulable de la même manière que l’utilisateur peut interagir avec les
contenus depuis son navigateur Web.

Par exemple, pour un événement appelé à l’adresse /agenda/2012/nuit-des-etoiles,
plusieurs chemins existeront pour obtenir des informations relatives à ce contenu :

• /agenda/2012/nuit-des-etoiles/adresses pour la liste des adresses
géolocalisées ;
• /agenda/2012/nuit-des-etoiles/similar pour la liste des évènements
similaires ;
• /agenda/2012/nuit-des-etoiles/related pour la liste des évènements connexes.
L’API sera accessible en lecture pour le public dans un premier temps.

Dans tous les cas, l’API sera dûment documentée. Un outil comme Swagger permettra à la fois
de générer les entrées de Webservice, sa documentation et les mécanismes de test.

Page 36/46

Moteur de recherche
Comme évoqué précédemment, le moteur de recherche sera de préférence :

• léger en terme de ressources machine ;
• fourni avec une API HTTP ;
• indépendant du langage de programmation employé par la plateforme ;
• idéalement scalable sur plusieurs machines sans avoir à revoir l’architecture technique
de la plateforme.

Des systèmes comme Solr ou ElasticSearch ont aujourd’hui fait leurs preuves en terme
d’efficacité, de robustesse et de capacité à s’intégrer dans tout type d’environnement.

Workflow des contenus
Le cycle de vie de chaque contenu de la plateforme est volontairement simple :

• Publié : c’est le statut par défaut de tout contenu créé sur la plateforme ;
• Bac à sable : c’est un statut intermédiaire attribué automatiquement en cas d’inactivité
(applicable uniquement à un « Projet », pour l’instant). Seul l’auteur du contenu et les
administrateurs peuvent le voir depuis l’interface publique de l’application ;
• Hors ligne : c’est le statut attribué à un contenu lorsqu’un administrateur souhaite en
masquer la visibilité, ou si un certain nombre de personnes ont indiqué un contenu
comme problématique/spam/préjudiciable. Le contenu n’est visible que depuis
l’interface d’administration ;
• Supprimé : le contenu est définitivement supprimé de la plateforme. Appliqué
seulement dans de rares cas, depuis l’interface d’administration.

Datastore
Le projet PINS souhaite s’inscrire dans une démarche Open Data, tant par le fait qu’elle
consommera des données ouvertes mais également en en republiant un maximum possible.

Conjointement aux Webservices fournis sous forme d’API REST, ainsi qu’à sa documentation
d’utilisation, les données sont à produire dans une démarche de Datastore : avoir en tête que
d’autres personnes se poseront la question de la manière d’utiliser les API pour bâtir des
services.

Page 37/46

L’ensemble devra être développé en respectant au mieux la checklist Open Data publiée sur
Opquast à cette adresse : https://checklists.opquast.com/opendata.

À terme, ces données et API seront republiées sur le Datastore de la Cub (http://data.lacub.fr),
de l’initiative départementale et régionale (http://www.datalocale.fr/) voire nationale
(http://data.gov.fr).

Linked Data
Optionnellement, il sera demandé au candidat de fournir ses données de manière liée, selon la
logique Linked Data : http://linkeddata.org/.

Autrement dit, en plus de fournir des données en silos, ceux-ci comporteront des informations
permettant de les relier avec des données de la plateforme PINS, ou avec des données
externes, elles-même reposant sur le même principe de Linked Data.

L’API proposera soit un format RDF complémentaire, soit un point d’entrée SPARQL, en sus.

Licence logicielle
La licence logicielle proposée par le titulaire du marché répondra à des contraintes de liberté
d’utilisation : du code, de sa redistribution et de sa modification. Toutefois, elle ne doit pas
empêcher l’utilisation du code dans un cadre commercial.

Cela permet entre autre à des entreprises et administrations tierces de contribuer au(x)
logiciel(s), et à ces mêmes entreprise et administrations, ou d’autres, de réutiliser ce code pour
des projets faisant appels à des besoins proches.

Cette licence devra permettre à ce projet d’atteindre un statut Open Source.

Distribution du code
Conséquence directe du précédent point, le code devra également être versionné au jour le jour

Page 38/46

sur une plateforme publique de type Github. La propriété des dépots sera transmises au GIP
GPV et ne sera en aucun cas coupé du public et ce, dans une optique de pérennité du code et
des projets qui en dépendraient.

L’application PINS pourra être découpée en plusieurs projets pour des besoins pratiques de
modularité.

Le suivi des anomalies se déroulera sur la même plateforme de gestion du code, ou sur une
interface facilitant le suivi et le pilotage du projet (de type Redmine, JIRA, Lighthouse etc.).

Environnement technique de réalisation
Tout choix dérogeant à ces grands principes devra être justifié par le soumissionnaire.

Langage de programmation
L’application pourra être développée dans un des langages suivants, au choix :

• Ruby ;
• Python ;
• JavaScript ;
• PHP (> 5.3).
Un framework sera employé pour gagner temps et sécurité (Rails, Node.js, Flask, Django etc.).
Le choix du framework ou de l’éventuel CMS devra être justifié.

Standards de codage
Le standard de codage employé sera un standard communément admis par la communauté du
langage en question (PEAR, PEP 8 etc.).

Page 39/46

Documentation
Le code sera documenté selon le standard en vigueur dans le langage de programmation
adopté : PHPDoc, JSDoc, Rdoc, Pydoc etc. Cette documentation est avant tout à destination
des développeurs et pourra être générée dans un autre format plus transportable, tel du
HTML.

La documentation technique sera versionnée au sein même du code projet, dans des fichiers
textes (brut, Markdown, RST ou autre du moment qu’il ne s’agit pas d’un format exotique). Elle
aidera les développeurs à s’approprier le projet, à justifier les choix techniques ou à expliciter
l’usage technique du code produit.

La documentation fonctionnelle pourra être fournie sous plusieurs formes :

• Prototypes fonctionnels ajustés (type Balsamiq) ;
• Wiki ;
• Documents PDF.

Stockage de données
La persistance des données devra tenir compte de plusieurs critères :

• Indexation du contenu dans un moteur de recherche ;
• Quantité importante de contenus ;
• Contenus liés entre eux ;
• Rapidité et fiabilité de lecture et d’écriture.

Les bases de données acceptées pourront être relationnelles (MySQL, PostgreSQL),
documentaires (MongoDB) ou encore sous forme de graphs (Neo4j, RDF).

Le choix devra être explicité.

Standards Web
L’application devra être consultable dans des formats Web communément employés : HTML5,
CSS2 et CSS3, JSON, XML, JavaScript 1.6. Ces langages devront être utilisés à bon escient,

Page 40/46

bien formatés et en étant accessibles au maximum, à défaut, en fournissant une dégradation
gracieuse.

Toutefois, le candidat devra veiller à ce que ces formats n’entrent pas en conflit avec les choix
de navigateurs (voir page 41).

Performances Web
Le candidat devra démontrer qu’il est soucieux des performances Web de l’application :
chargement rapide (temps d’interactivité de l’ordre de la seconde), maintien des performances
d’affichage dans le temps malgré l’augmentation du volume de données en base, interface
réactive, dimensionnement et optimisation des images, pas de contenus ou scripts superflus.

Il emploiera des techniques de minification et de compression, tout en veillant à ce que ça ne
crée pas de bugs d’exécution.

Le candidat fournira un outil de suivi des métriques de chargement sur des pages clés de
l’application. Par exemple, Yottaa.

Compatibilité des navigateurs Web
Le rythme de mise à jour des navigateurs s’est accentué depuis 2010. Il est toutefois demandé
que le site soit compatible avec les navigateurs ayant au moins 10% de part de marché :

• Internet Explorer 9 ;
• Firefox 10 ;
• Chrome 17 ;
• Opera 11 ;
• Safari Mobile (iOS 4+, Android 2.3+) ;
• Internet Explorer Mobile (Windows Phone 7+).

Si l’effort (temps, humain et financier) pour assurer une compatibilité devait être trop
important ou manquant de pertinence, une solution de contournement devra être proposée
(dégradation gracieuse, affichage ou comportement différent mais cohérent).

Page 41/46

L’utilisation de certaines fonctionnalités préférera se baser sur les capacités du navigateur que
son numéro de version (philosophie Modernizr).

Bonnes pratiques Opquast
L’application devra être réalisée en respectant au maximum les bonnes pratiques de qualité
Opquast (http://www.opquast.com/) et en tenir compte via l’outil de reporting adapté
(https://reporting.opquast.com/).

Seul un respect des règles applicables à l’application est demandé.

Mesure d’audience
L’application devra voir son audience mesurée via des outils comme Quantcast, Google
Analytics ou Xiti. Cet outil permettra de suivre la progression du trafic ou son origine afin de
procéder à des améliorations techniques, si nécessaire.

Extensibilité de l’application
De nouvelles fonctionnalités pourront être ajoutés à l’application moyennant des
développements supplémentaires, commandés par le GIP GPV des Hauts de Garonne ou par
des contributeurs externes.

Ces développements ne devront toutefois pas avoir à remettre fondamentalement en cause
l’architecture de l’application. Le recours à des évènements ou des mécanismes de filtres
seront employés pour étendre des parties de l’application sans à modifier le code d’origine.

Une convention, un fichier de configuration ou un panneau de réglage global de l’application
permettra d’activer ou de désactiver certains modules si nécessaire.

Page 42/46

Sécurité
L'application devra être développée de manière à garantir au maximum la sécurité de
l'application et des données manipulées.

Un audit de sécurité pourra être engagé par le GIP GPV. Le titulaire du marché s'engage à
corriger les éventuelles failles de sécurité qui pourraient être soulevés lors de cet audit.

Déploiement
Le déploiement de l’application utilisera des mécanismes de livraison automatisée, versionnés
avec l’application. Les déploiements en production seront effectués après validation du GIP
GPV.

Les scripts de déploiement seront documentés et permettront :

• de modifier la structure de la base de données si nécessaire ;
• patcher les fichiers ;
• regénérer les caches éventuels ;
• lancer les tests unitaires et/ou fonctionnels ;
• revenir à une version antérieure en cas de problème majeur ou de défaillance.

Sauvegarde et restauration
Une procédure de sauvegarde et de restauration du système devra être proposée par le
candidat, selon un mode opératoire à élaborer avec l’hébergeur.

Mise en œuvre
Initialisation de l’application
Pour la mise en ligne de l’application, le titulaire construira l’ensemble des pages formant le
site à partir des textes, images, sons et vidéos qui auront été collectés ou élaborés par les
acteurs du GIP GPV des Hauts de Garonne.

Page 43/46

Le titulaire fournira également les moyens d’intégration de contenus en masse (annuaire
d’entreprises, d’associations, agendas etc.).

Organisation du projet
L’équipe projet sera constituée :

• du chargé de mission PINS du GIP GPV des Hauts de Garonne ;
• du chef de projet du titulaire en charge de réaliser l’application.
Des réunions de travail seront organisées, dans les locaux du GIP GPV des Hauts de
Garonne, autant que de besoin, et seront composées de l'équipe projet, ainsi que de tous les
intervenants nécessaires au traitement de l'ordre du jour aussi bien du coté du titulaire du
marché que du coté du GIP GPV.

L'ordre du jour sera élaboré conjointement entre les membres de l'équipe projet et diffusé
avant chaque réunion à l'ensemble des participants. Chaque réunion fera l'objet d'un compte-
rendu et d'un relevé de décisions à la charge du titulaire du marché.

Un comité de pilotage se réunira chaque fois que des décisions importantes seront à
prendre et au moins à chacune des étapes suivantes :

• Pour le lancement du projet,
• A la validation des spécifications ou en début de réalisation du projet,
• Avant le démarrage en production.
Ce comité de pilotage sera composé des équipes projet décrites ci-dessus, ainsi que des
directeurs, de tout acteur nécessaire et un responsable de la société titulaire du marché
habilité à décider en son nom.

Ces réunions feront l'objet d'un compte-rendu et d'un relevé de décisions à la charge du
titulaire du marché.

Hébergement technique
Il sera effectué par le titulaire du marché d’hébergement (distinct du présent marché) et sous
la responsabilité du GIP GPV.

Le développement devra permettre le fonctionnement sur plusieurs frontaux en cluster et un
serveur de base de données.

Page 44/46

Installation et paramétrage des logiciels
La liste des logiciels nécessaires au bon fonctionnement de l’application et leur configuration
seront fournis par le titulaire du marché, à défaut de pouvoir être automatisés.

Assistance
Le titulaire du Marché doit définir l’assistance au démarrage sur site dans son offre en
précisant les interventions et les compétences mises en œuvre. Cette assistance comporte
toutes les prestations d’aide, de conseil et d’interventions pour parvenir à un fonctionnement
opérationnel des systèmes d'information fournis, notamment en terme de paramétrage.

Les intervenants devront avoir l’expérience de configurations techniques, matérielles et
fonctionnelles identiques. Le nombre de journées d’assistance doit être suffisant pour que les
informaticiens, les administrateurs des systèmes et les utilisateurs de la Collectivité maîtrisent
les fournitures utilisées.

Garanties et maintenance
Les fournitures produites par le titulaire du marché sont toutes garanties pour une période
d’une année à partir de la Mise en ordre de marche. A ce titre le titulaire du marché s’engage à
respecter les délais décrits.

Une assistance téléphonique sera assurée pendant la période de garantie pour le chargé de
mission du GIP GPV. L’assistance utilisateur sera elle assurée par ces mêmes administrateurs.

Au-delà de la période de garantie, les correctifs seront traités comme des évolutions et feront
l’objet de commandes.

Prestations
Le GIP GPV des Hauts de Garonne souhaite la réalisation de ce projet en mode agile.
Toutefois, le cadre légal contraint quelque peu le système. Ainsi, l’enveloppe financière sera
fixe, l’ensemble des modules commandés également mais le détail des fonctionnalités pourra
être ajusté de manière pragmatique, afin de répondre à la fois aux exigences de l’agilité et de la
réussite du projet.

Page 45/46

Ainsi :

• le GIP GPV émet des souhaits au travers de ce présent marché ;
• elle définit les priorités de réalisation au travers d’un backlog produit ;
• le titulaire du marché estime les charges de sorte à pouvoir
◦ soit décaler l’ordre d’exécution d’une tâche ;
◦ soit la découper en plusieurs tâches, dont chacune bénéfiera d’une priorité de
réalisation différente ;
• le GIP GPV pose les contraintes supplémentaires éventuelles par rapport à celles déjà
connues du titulaire (réalisées ou connues lors des prestations précédentes sur le
présent marché).
Malgré cette formule, le GIP GPV attend du titulaire du marché un engagement réel sur les
résultats, dans le respect des règles et des contraintes du GIP GPV. Des pénalités sauraient
être appliquées si le titulaire n’offrait pas satisfaction dans son œuvre.

Sous cette forme, la prestation du titulaire comprend :

• Le pilotage du projet coté titulaire ;
• La constitution du backlog au regard des besoins (spécifications techniques,
fonctionnelles, organisationnelles, ergonomiques, graphiques etc) ;
• Les modifications, corrections, apports de spécifications demandées par le GIP GPV ;
• La fourniture des systèmes et logiciels ;
• Les développements ;
• Les installations, les tests unitaires ;
• L’intégration en simulation, les vérifications de fonctionnement en intégration ;
• Les vérifications et résultats de sécurité, de fiabilité et de performances des fournitures
et services et de l’ensemble après intégration ;
• Les documentations de conception, de développement, d’intégration, d’utilisation,
d’administration, d’exploitation ;
• La correction de toute anomalie ou de tout dysfonctionnement sur les réalisations
faites ou sur les fournitures ou services du projet ou sur les développements,
fournitures ou services impactés par le projet ;
• La correction de tout écart vis-à-vis des spécifications validées par le GIP GPV.

Planning et itérations
Le soumissionnaire devra proposer un planning des itérations et de mise en œuvre au plus tot.

Page 46/46

Cahier des charges PINS version 1 (CCTP)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Semelhante a Cahier des charges PINS version 1 (CCTP)

Semelhante a Cahier des charges PINS version 1 (CCTP) (20)

Cahier des charges PINS version 1 (CCTP)