Évolution de la plateforme numérique de participation

Le marché porte sur l’évolution de la plateforme numérique de participation de Bourges 2028, ainsi que sur son hébergement et sa maintenance jusqu’au terme du marché. La solution doit conserver une architecture cohérente, une base de données commune et un compte utilisateur durable entre les sessions et éditions.

Administration, appels à projets et évaluation

La plateforme doit gérer les profils de candidats, lauréats, bénévoles, administrateurs, membres de jury et responsables de mission. Un même utilisateur peut cumuler plusieurs statuts sans créer de nouveau compte. Les droits doivent être paramétrables par module, données, candidatures, évaluations, bénévoles, statistiques, exports et sessions.

Les administrateurs doivent pouvoir créer, modifier, clôturer et archiver les sessions annuelles, conserver l’historique, personnaliser les formulaires de candidature, gérer les champs obligatoires ou facultatifs, les rubriques, les types de réponse et les pièces justificatives. La solution doit assurer la numérotation automatique des dossiers, les notifications liées aux étapes de traitement et le recueil des informations des lauréats. Les données doivent être exportables notamment en CSV et Excel.

Le module jury doit permettre de créer les jurys, gérer leurs membres et droits, associer un jury à une session ou un appel à projets, affecter les dossiers de manière sécurisée, paramétrer les grilles, pondérations, notes, commentaires et consignes, conserver l’historique, consolider les évaluations, classer les dossiers et exporter les résultats.

Bénévoles, missions, agenda et communication

Le CRM bénévoles doit conserver une fiche individuelle et un historique de participation comprenant notamment coordonnées, disponibilités, compétences, centres d’intérêt, langues, missions et événements. Les organisateurs doivent pouvoir exporter les seules informations nécessaires aux missions.

Les missions bénévoles doivent être créables, publiables, dupliquées et archivées, avec intitulé, description, dates, créneaux, horaires, lieu, jauge, profils recherchés et informations pratiques. La solution doit gérer les inscriptions, listes d’attente, blocage à jauge atteinte, validations, refus, désistements, réaffectations, conflits horaires et historique.

Le module agenda doit gérer calendriers, listes, filtres, rencontres, réunions, formations, ateliers et autres événements, avec inscriptions, désistements, capacités, listes d’attente, participants, présences, exports et historique individuel.

La communication doit permettre de créer des modèles d’e-mails, d’automatiser les envois et de cibler des groupes selon le profil, la session, le territoire, la mission, le statut ou la participation. Les destinataires doivent pouvoir être vérifiés avant envoi.

Pilotage, documents et expérience utilisateur

Les tableaux de bord doivent suivre candidatures, projets, lauréats, bénévoles, missions, inscriptions, rencontres et participations. Les données doivent être filtrables par session, édition et période, tout en conservant la distinction entre les sessions. Les indicateurs doivent être exportables notamment en CSV et Excel.

La gestion documentaire doit permettre aux utilisateurs habilités de déposer et d’associer des flyers, programmes, descriptifs, pièces administratives et documents liés aux projets, bénévoles ou missions. La taille maximale est de 50 Mo par fichier ; les formats pris en charge et les modalités de stockage sont à préciser dans l’offre.

Les interfaces doivent être adaptées aux ordinateurs, tablettes et smartphones, avec une attention particulière aux parcours des bénévoles. Les écrans, formulaires et tableaux doivent rester lisibles et limiter les actions inutiles. Les bonnes pratiques d’accessibilité numérique doivent être appliquées.

Sécurité, données et réversibilité

Les développements doivent sécuriser l’authentification, les droits, les données sensibles, les exports, les dépôts de fichiers et la traçabilité des actions, notamment au regard du RGPD. Toute vulnérabilité ou anomalie de sécurité doit être signalée à Bourges 2028 sans délai. Le titulaire traite les données uniquement pour les finalités du marché et signale toute violation de données dans les 24 heures.

Les évolutions du schéma de données, des API, de la base ou du stockage doivent faire l’objet d’une analyse d’impact. Lorsque nécessaire, un plan de migration, sauvegarde, reprise, contrôle de cohérence et retour arrière doit être proposé. Les données doivent être récupérables dans des formats exploitables et documentés. Le code source, la documentation, l’architecture, les configurations et les dépendances des développements spécifiques doivent être remis.

Tests, livrables et maintenance

Chaque évolution doit être testée avant mise en production : tests fonctionnels, parcours multi-profils, échanges entre modules et tests sur ordinateur, tablette et smartphone. Un environnement de préproduction doit être utilisé lorsque l’architecture le permet. Le titulaire fournit les résultats des tests et corrige les anomalies constatées.

Les livrables peuvent comprendre les spécifications fonctionnelles, les maquettes ou prototypes lorsque les interfaces évoluent significativement, ainsi que le code source. Le titulaire accompagne les équipes de Bourges 2028 et désigne un chef de projet référent. Toute mise en production est soumise à la validation écrite et préalable de l’acheteur.

La maintenance préventive, corrective et évolutive réglementaire est incluse dans le prix forfaitaire. Les interventions préventives sont réalisées entre 20h00 et 07h00. Les délais cibles de résolution sont de 4 heures ouvrées pour une anomalie bloquante, 1 jour ouvré pour une anomalie majeure et 3 jours ouvrés ou la prochaine mise à jour pour une anomalie mineure. La disponibilité annuelle doit être supérieure ou égale à 99,5 %, calculée entre 07h00 et 20h00 hors fenêtres de maintenance préventive validées.