Cahier des charges PINS version 1 (CCTP)

Plateforme d'innovation numérique et sociale dela Rive Droite

Cahier des Clauses Techniques Particulières

Émetteur GIP GPV Hauts de Garonne

Date Février 2012

/46CyneticMonkey 12 rue du levant

33140 Villenave d’Ornon+336 08 40 35 49 [email protected] @oncletom cyneticmonkey.com

Table des matièresTable des matières................................................................................................................2Objet de la commande..........................................................................................................5Le contexte............................................................................................................................7

Le GIP GPV des Hauts de Garonne................................................................................ 7Le projet PINS..................................................................................................................8Objectifs généraux........................................................................................................... 8

Description des besoins fonctionnels................................................................................. 9Accessibilité...................................................................................................................... 9

Terminaux d’accès............................................................................................................... 10Interface.............................................................................................................................. 10Débit.................................................................................................................................... 11

Fonctionnalités transverses.......................................................................................... 11Appréciation du contenu..................................................................................................... 11Signalement du contenu......................................................................................................12Export du contenu............................................................................................................... 13Affichage dual : contenu/carte............................................................................................ 13Filtres d’affichage................................................................................................................ 15Vie privée............................................................................................................................. 16

Agenda............................................................................................................................16Objectifs.............................................................................................................................. 16Page d’accueil / Résultat de filtre....................................................................................... 17Groupe d’évènements..........................................................................................................18Détail d’un événement......................................................................................................... 19Ajout d’un événement.......................................................................................................... 20

Exploration du territoire................................................................................................ 20Objectifs.............................................................................................................................. 20Les entités........................................................................................................................... 20Page d’accueil / résultat de filtre........................................................................................ 22Détail d’une ressource......................................................................................................... 22Ajouter une ressource......................................................................................................... 24

Recherche.......................................................................................................................24Objectifs.............................................................................................................................. 25Transversalité...................................................................................................................... 25Fonctionnalités complémentaires....................................................................................... 26

Wiki collectif.................................................................................................................. 26



Objectifs.............................................................................................................................. 27Page d’accueil / résultat de filtre........................................................................................ 27Détail d’un document.......................................................................................................... 27

Petites annonces............................................................................................................29Objectifs.............................................................................................................................. 30Page d’accueil / résultat de filtres....................................................................................... 30Détail d’une annonce........................................................................................................... 30

Projets citoyens..............................................................................................................31Objectifs.............................................................................................................................. 31Page d’accueil / résultat de filtre........................................................................................ 31Label projet.......................................................................................................................... 32Les idées.............................................................................................................................. 32Détail d’un projet................................................................................................................. 33

Webservices................................................................................................................... 34Tableaux de bord............................................................................................................34Administration et modération....................................................................................... 35

Description des besoins techniques..................................................................................36API RESTful................................................................................................................... 36Moteur de recherche......................................................................................................37Workflow des contenus................................................................................................ 37Datastore........................................................................................................................37Linked Data.....................................................................................................................38Licence logicielle............................................................................................................ 38Distribution du code...................................................................................................... 38

Environnement technique de réalisation...........................................................................39Langage de programmation...........................................................................................39Standards de codage..................................................................................................... 39Documentation...............................................................................................................40Stockage de données.....................................................................................................40Standards Web...............................................................................................................40Performances Web........................................................................................................ 41Compatibilité des navigateurs Web.............................................................................. 41Bonnes pratiques Opquast............................................................................................42Mesure d’audience......................................................................................................... 42Extensibilité de l’application..........................................................................................42Sécurité...........................................................................................................................43



Déploiement................................................................................................................... 43Sauvegarde et restauration........................................................................................... 43

Mise en œuvre.................................................................................................................... 43Initialisation de l’application..........................................................................................43Organisation du projet...................................................................................................44Hébergement technique................................................................................................ 44Installation et paramétrage des logiciels......................................................................45Assistance.......................................................................................................................45Garanties et maintenance..............................................................................................45

Prestations..........................................................................................................................45Planning et itérations......................................................................................................... 46



Version Auteur Date Commentaire1.0 Thomas Parisot 13/02/2012 Version initiale

Objet de la commandeObjet 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.



http://www.rivedroitenumerique.org/

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.



Le contexteIl 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 GaronneLes 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-



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 connait 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



http://www.Facebook.com/jaime.larivedroite

http://twitter.com/rivedroitebx

http://www.blog-rivedroite.fr/

Description des besoins fonctionnelsLes 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.



Terminaux d’accèsL’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.

InterfaceLes 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, boites 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).



DébitL’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 transversesCertaines 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 contenuDans 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é.



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 contenuLa 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



é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 contenuAfin 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/carteSuite 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.).



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



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 apparait 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’affichageL’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.



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.

AgendaL’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)



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

Page d’accueil / Résultat de filtreCette 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 uneL’é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ènementsLes 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.



Coups de projecteurLes 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 populairesLes é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ènementsLes 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.



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énementCette 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.



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

Ajout d’un événementL’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 ;



• 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 ;◦ URL du site Web ;◦ Adresse email de contact ;◦ 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 ;◦ URL du site Web ;◦ Adresse email de contact ;◦ 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).



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.



Un premier emplacement résumera l’essentiel des informations à connaitre :

• 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é ;



• 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.



http://www.servicelab.fr/

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 connait 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.



Fonctionnalités complémentairesLe 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.



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.

Page d’accueil / résultat de filtre

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 :



◦ 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.



À 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).



http://substance.io/

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 ;



◦ 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.

Page d’accueil / résultat de filtreLa page d’accueil fournit un ensemble d’informations couvrant l’activité des projets au sein de



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 projetLes 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éesUne « idée » est un concept intermédiaire entre « rien » et un projet. Des individus peuvent



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.



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



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).



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 techniquesCette 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 RESTfulDans 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.



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.



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



http://linkeddata.org/

http://data.lacub.fr/

https://checklists.opquast.com/opendata

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éalisationTout choix dérogeant à ces grands principes devra être justifié par le soumissionnaire.

Langage de programmationL’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.).



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,



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).



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.



https://reporting.opquast.com/

http://www.opquast.com/

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’applicationPour 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.



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

Organisation du projetL’é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 techniqueIl 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.



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.

AssistanceLe 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é maitrisent les fournitures utilisées.

Garanties et maintenanceLes 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.

PrestationsLe 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.



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érationsLe soumissionnaire devra proposer un planning des itérations et de mise en œuvre au plus tot.



Cahier des charges PINS version 1 (CCTP)

Documents

Transcript of Cahier des charges PINS version 1 (CCTP)