Maintenance et évolution de la plateforme des repères de crues

Le marché couvre le maintien en condition opérationnelle et les évolutions de la plateforme collaborative de recensement des repères et marques d’inondation. Elle permet au public de consulter les données et aux contributeurs, gestionnaires et administrateurs de les saisir, importer, vérifier, publier, valider et exploiter.

La plateforme s’appuie sur Drupal 11, PHP 8.4, PostgreSQL 17/PostGIS 3.5 et Debian 13, avec Apache et des interfaces cartographiques fondées notamment sur OpenLayers. Le référentiel compte environ 70 000 sites et 95 000 repères, avec une croissance estimée à environ 8 000 repères par an (700 par mois) et des photographies et documents associés. En juillet 2026, l’application et ses fichiers de production et de préproduction représentaient environ 175 Go, dont environ 80 Go en production ; ces volumes sont indicatifs et susceptibles d’évoluer.

Initialisation et maintien en condition opérationnelle

• INI1 : démarrage et organisation du projet, PAQ, audit et métriques de qualité et sécurité du code, analyse de l’obsolescence et état des lieux de la dette technique. Cette phase dure au maximum 3 mois.
• INI2 : acquisition de l’autonomie technique, réunions et mise en place de l’environnement de développement avec sa documentation d’architecture ; durée maximale de 3 mois. Elle peut être menée en parallèle d’INI1.
• Maintenance corrective : qualification et suivi des anomalies bloquantes, majeures ou mineures, conception et développement des corrections, tests internes, mise à jour documentaire et suivi. Pour une anomalie bloquante, prise en charge sous 1 jour ouvré et rétablissement, y compris par contournement si nécessaire ; résolution définitive sous 4 jours ouvrés au maximum. Pour une anomalie majeure, prise en charge sous 4 jours ouvrés ; le délai de résolution définitive est fixé avec la personne publique.
• Support téléphonique et outil de suivi les jours ouvrés, du lundi au vendredi, de 8 h à 18 h. Les corrections et adaptations sont également reportées sur les versions de test maintenues en parallèle.
• Maintenance adaptative : suivi de l’obsolescence et de la compatibilité, puis adaptations aux évolutions des composants, de la sécurité, des services web, de la messagerie et des navigateurs, après accord de la personne publique.

Évolutions, développements et livraisons

Les évolutions peuvent comprendre l’analyse du besoin (éventuellement omise si celui-ci est trivial), les spécifications générales et détaillées, les développements, la documentation et la recette. Le titulaire propose un découpage en sprints ; l’analyse ou les spécifications peuvent être réalisées par le maître d’ouvrage et ne sont alors pas commandées au titulaire. L’analyse doit notamment présenter des scénarios techniques, leurs avantages et inconvénients et une estimation approximative des coûts. Les spécifications comprennent, selon le besoin, règles de gestion, cas d’usage, impacts sur les données, maquettes d’interfaces, architecture et plan de tests.

Les livraisons comprennent le code source et les tests unitaires, les notes de version, les résultats de tests fonctionnels, unitaires, de performance et de sécurité, les contrôles de compatibilité navigateurs, les métriques de qualité et de sécurité, une archive installable et les procédures de mise à jour automatisées. La documentation concernée est tenue à jour et fournie dans un format modifiable. Une démonstration est prévue avant les premières livraisons et lors des itérations ; une assistance à l’installation est également requise.

Les développements doivent privilégier les mécanismes standards de Drupal, ne pas modifier directement son cœur ni les modules tiers, et soumettre les nouvelles dépendances à validation. Les contrôles automatisés, l’intégration continue, les tests adaptés à chaque évolution et le suivi des vulnérabilités sont requis. Pour les pages de recherche et actions de consultation, le temps de réponse cible est inférieur à 2 secondes, avec un maximum admissible de 5 secondes pour les actions les plus complexes. Les interruptions de service doivent être limitées ; toute intervention susceptible d’affecter la disponibilité ou les performances est identifiée, planifiée et validée préalablement.

La plateforme comprend des environnements de développement et de démonstration à la charge du titulaire, un environnement de recette fourni par le SCV, ainsi que des environnements de préproduction et de production pour le site officiel et sa réplique de formation. Avant la migration vers l’hébergement ministériel prévue courant 2027, les déploiements du site officiel sont pilotés par le titulaire en lien avec l’hébergeur privé et le SCV ; ensuite, le SCV pilote les déploiements de test et de préproduction avec l’hébergeur ministériel. Toute livraison est validée en préproduction avant mise en production.

Recette, pilotage et réversibilité

Les évolutions font l’objet d’une phase de réception et d’installation, d’une vérification d’aptitude (VA) puis d’une vérification de services réguliers (VSR). Les bons de commande précisent les délais ; à défaut, la VA dure 2 mois et la VSR 3 mois. Les développements évolutifs et correctifs bénéficient d’une garantie d’un an à compter de leur réception.

Le comité de suivi est hebdomadaire par défaut, avec suivi des commandes, livrables, tickets, corrections, paiements et difficultés ; le COPIL élargi est organisé a priori tous les 3 mois, sans intervalle supérieur à 6 mois. La réversibilité ou transférabilité, déclenchée par ordre de service, comprend la mise à jour et la remise de la documentation, du code source, de la base et des dernières sauvegardes, du journal des corrections et évolutions, ainsi qu’une assistance à la reprise des environnements et une présentation de l’architecture, du code et des procédures d’administration et d’exploitation.