Ajouts fonctionnels et maintenance d’une application de gestion de la formation continue

Le marché couvre la finalisation et l’évolution de l’application du Service de formation continue de l’Université de Strasbourg, l’audit de ses performances, la mise en œuvre d’objectifs prioritaires issus d’un audit antérieur, ainsi que la maintenance préventive et corrective pendant toute la durée du marché. La phase 0 de transfert de compétences et d’appropriation dure six semaines et doit commencer dès la notification. Le transfert de compétences par l’équipe sortante est prévu.

Modules et fonctions métier

Le module « Offre de formation » comprend la génération des catalogues et programmes au format XML CDM-FR, leur dépôt dans une collection dédiée de l’instance eXist-db existante et une API REST destinée notamment à l’interrogation des données par le prestataire du site web. L’instance eXist-db est administrée et exploitée par l’Université ; le titulaire assure l’interfaçage. Pour les demandes d’impression, le titulaire génère et dépose le flux XML : l’imprimeur génère ensuite le PDF. Le formulaire de pré-inscription et son appel à l’API côté site web relèvent du prestataire web de l’Université ; le titulaire réalise l’API et le traitement des pré-inscriptions dans l’application.

Le suivi financier gère chaque session de la simulation à la clôture comptable, avec catégorisation des dépenses, calculs automatisés, suivi des vacations et des bons de commande, traçabilité des pièces comptables, rapprochement du prévisionnel et du réalisé, alertes de seuil et exports PDF, Excel ou CSV. Le module d’organisation centralise sessions et séquences, tâches administratives configurables et rappels, salles, affiches, demandes d’achat et leur intégration au suivi financier.

Le pilotage comprend des tableaux de bord adaptés aux profils, des composants personnalisables pour les utilisateurs internes, des requêtes prédéfinies filtrables avec export CSV/XLSX et, sur bons de commande, un outil de requêtage avancé respectant la gouvernance des données. Toutes les personnes qui consultent les tableaux de bord, y compris les responsables scientifiques, les composantes et les services centraux, disposeront d’un compte Unistra et s’authentifieront via le CAS. Les connecteurs prévus concernent l’évaluation de satisfaction et l’émargement numérique ; les solutions ne sont pas encore arrêtées, et l’Université prend en charge les éventuels frais d’accès à leurs API.

Audit, maintenance et niveaux de service

Pour les recommandations de l’audit existant, le titulaire doit atteindre un socle d’objectifs portant sur la sécurité du code et de la CI/CD, la qualité et la maintenabilité, les contrôles automatisés, la couverture et l’exécution des tests, la documentation maintenable, ainsi que la suppression des incompatibilités et dépendances à risque et l’amélioration des performances. Des solutions différentes de celles proposées dans l’annexe sont admises si elles atteignent un niveau au moins équivalent. Les lenteurs seront considérées corrigées au regard de scénarios représentatifs et d’une volumétrie comparable à la production ; les seuils seront définis conjointement à l’issue de l’audit et vérifiés par des tests documentés et reproductibles.

La TMA inclut le support, la maintenance corrective et préventive, les mises à jour de sécurité, la surveillance et le maintien à jour de la stack. La prise en compte d’un dysfonctionnement est requise sous quatre heures ouvrées. La TMA et sa facturation démarrent à la notification, y compris pendant la phase 0. Le taux de disponibilité de 95 % s’applique à compter de la phase 1, après les six semaines de phase 0, jusqu’à la recette définitive du jalon 2 ; le taux de 99 % s’applique ensuite. En phase 0, la maintenance et la continuité de service restent dues, mais le seuil de 95 % et sa pénalité ne s’appliquent pas.

Chaque livrable admis bénéficie d’une garantie de douze mois. Les corrections relevant de la garantie sont sans surcoût et ne sont pas imputées sur la TMA ; les délais maximaux sont de cinq jours ouvrés pour les anomalies bloquantes ou majeures et de dix jours ouvrés pour les anomalies mineures. La maintenance évolutive de base comprend dix jours-homme par an ; les jours supplémentaires, la personnalisation dynamique des tableaux de bord et le requêtage avancé relèvent de bons de commande. La réversibilité sortante est gratuite et doit garantir la continuité de service.

Déploiement, hébergement et contraintes techniques

Le cycle de livraison va du développement aux environnements de test et de pré-production, puis à la production après recette définitive. Le SFC dispose de dix jours ouvrés pour tester les livrables et notifier ses réserves. Les environnements de développement, pré-production et production, la chaîne CI/CD GitLab, Portainer et Commvault existent déjà. L’Université fournit et maintient l’infrastructure sous-jacente OpenStack ; le titulaire gère les instances, la configuration du projet, les correctifs, la supervision et les sauvegardes selon les responsabilités prévues au marché.

L’hébergement est imposé dans le Data Center de l’Université, au sein d’un projet IaaS OpenStack dédié. L’authentification passe par le CAS et les droits sont gérés localement dans l’application. Les technologies existantes comprennent notamment React, Next.js, Material-UI, NestJS, GraphQL, REST, Prisma, PostgreSQL, S3, Cypress, GitLab, Docker et Portainer. Les API doivent être documentées selon OpenAPI/Swagger et utiliser des protocoles sécurisés et des formats standards ; le XML CDM-FR reste requis pour les catalogues. Le code produit appartient exclusivement à l’Université.

La partie forfaitaire est estimée à 120 000 € HT et la partie à bons de commande à 30 000 € HT sur cinq ans. Le maximum de 95 000 € HT porte uniquement sur les bons de commande. Le critère de prix est évalué sur le montant total TTC du DQE, qui comprend forfait et prestations à bons de commande.