Cahier des charges — E-Grenier V2.1

Commercialisation des produits vivriers, traçabilité des lots et convergence avec OCPV Info-Prix
Bénéficiaire : Office d’aide à la Commercialisation des Produits Vivriers — OCPV
Proposition élaborée par : CIACEMS
Date : 18 septembre 2026
Version : 1.4 — projet de cahier des charges à examiner avec l’OCPV
Document associé : Offre technique et financière CIACEMS — E-Grenier V2.1, version 1.4

1. Objet et résultats attendus

Le présent cahier des charges définit la plateforme E-Grenier V2.1 à concevoir, réaliser, déployer et accompagner pour l’OCPV. La solution reliera les producteurs, les acheteurs, les agents des hubs et les services de pilotage autour d’un parcours traçable : déclaration d’une récolte, réception et contrôle, publication commerciale, réservation, paiement et enlèvement.

La prestation comprend explicitement la reprise et la refonte du code source E-Grenier V2 fourni par l’ancien prestataire, ainsi que la production de la documentation technique du code refondu. CIACEMS analysera les éléments remis, déterminera les composants à conserver, à restructurer ou à remplacer et réalisera les adaptations nécessaires au périmètre V2.1. La documentation sera produite pendant ces travaux et remise avec les versions du logiciel.

La refonte technique est arrêtée sur Python avec Django pour les services backend, Django Ninja pour les API et Vue.js pour l’application web SPA, avec les fonctions PWA prévues. La cible sera une architecture intégralement organisée en microservices, conteneurisée avec Docker, orchestrée par Docker Swarm et administrée au moyen de Dokploy sur des VPS hébergés localement. PostgreSQL, Redis et Celery assureront respectivement la persistance, le cache et les traitements asynchrones.

La V2.1 devra permettre à l’OCPV de disposer d’un système sur mesure, accessible sur téléphone et ordinateur, dont les données opérationnelles contribueront à l’information sur les marchés. Son développement et son évolution seront conduits avec les agents et les utilisateurs, grâce à un accompagnement en présentiel et à une maintenance organisée dans la durée.

Les résultats attendus sont les suivants :

• reprendre et refondre le code source V2 pour obtenir un socle maintenable, documenté et adapté aux exigences V2.1 ;
• remplacer l’inscription libre par un enrôlement producteur contrôlé par l’OCPV, avec plusieurs moyens de connexion pour les comptes validés ;
• rendre commandables uniquement les quantités effectivement contrôlées et disponibles ;
• conserver la trace des opérations et des responsabilités sur chaque lot ;
• suivre les paiements et leurs exceptions jusqu’à la confirmation ;
• rapprocher les données de commercialisation et les informations de marché ;
• donner aux équipes de l’OCPV les moyens d’administrer le service et de participer à ses évolutions.

Les exigences ci-dessous constituent la proposition de référence. Les hypothèses de volume, de calendrier et de service seront arrêtées lors du cadrage. Toute modification du périmètre financé fera l’objet d’une estimation et d’une décision écrite avant sa réalisation.

2. Périmètre de réalisation

2.1 Périmètre initial couvert par l’offre

La période de 12 mois est une hypothèse de rédaction pour cette proposition ; sa durée sera confirmée dans l’offre retenue. Elle commence à la réception de la mise en service, selon le procès-verbal convenu.

2.2 Hypothèses proposées pour dimensionner la prestation

Ces valeurs définissent une base de chiffrage et de recette ; elles ne décrivent pas les volumes réels de l’OCPV.

La capacité technique de référence permet une montée en usage au-delà du pilote. L’accompagnement physique d’une généralisation nationale sera planifié et chiffré selon les sites et moyens retenus.

2.3 Extensions à programmer séparément

La trajectoire comprend des applications mobiles Android et iOS développées avec Flutter, en langage Dart, et distribuées sur les stores. Elles utiliseront les API Django Ninja du backend et les mêmes règles métier et d’habilitation que la plateforme web. Elle comprend également des services USSD, WhatsApp et SMS interactifs, un numéro vert, une assistance vocale et l’élargissement des analyses prédictives. Leur mise en production complète ne fait pas partie du forfait initial. Chaque extension sera spécifiée et chiffrée avec ses dépendances opérateurs et ses frais récurrents.

L’accès mobile initial sera assuré par la PWA depuis les navigateurs compatibles. La généralisation nationale, l’équipement des hubs, les terminaux, les balances connectées et l’exploitation physique des activités logistiques seront également organisés hors de ce forfait logiciel.

3. Utilisateurs et responsabilités

L’OCPV désignera les personnes habilitées à valider les règles de gestion, les données de référence, les contrôles au hub et la recette. CIACEMS assurera la conception, la réalisation, la documentation et l’accompagnement du périmètre convenu.

4. Exigences fonctionnelles

4.1 Accès, authentification et enrôlement

Constat sur E-Grenier V2.0 : l’écran d’inscription (register) est accessible à tous, sans vérification préalable : n’importe qui peut ouvrir un compte producteur, y compris à tort. Par ailleurs, le producteur peut faire apparaître une récolte avant contrôle de l’OCPV ; seuls les agents en sont informés, alors que la publication sur la marketplace relève de l’OCPV.

Orientation V2.1 : un espace d’enrôlement des producteurs remplace l’inscription libre. Le candidat dépose une demande ; l’OCPV vérifie les pièces KYC, valide ou refuse avec motif, puis génère les accès du producteur. Une fois authentifié, il déclare ses récoltes reçues et contrôlées ; seuls les agents habilités de l’OCPV publient les offres sur la marketplace. L’acheteur intéressé règle directement le producteur sur mobile money — le produit ayant été vérifié par l’OCPV — et les taxes ou recettes institutionnelles dues à l’OCPV sont identifiées et tracées à part du prix de la marchandise.

L’ajout d’Auth0 vise à diversifier les moyens de connexion en complément du SMS OTP, à réduire éventuellement la dépense de SMS à grande échelle et à permettre un accès alternatif lors d’une indisponibilité du service SMS. Les alternatives devront être préparées avant un incident et rattachées au même compte métier de manière sécurisée.

Les moyens complémentaires ne seront pas rendus obligatoires pour les producteurs qui utilisent le SMS OTP. La formation présentera leur préparation et leurs conditions d’usage. Les abonnements Auth0 et les services de messagerie seront souscrits selon les dispositions financières retenues.

4.2 Déclaration des lots et préparation logistique

La planification initiale de collecte sera manuelle et assistée par le système. L’optimisation automatique des tournées et le suivi de véhicules en temps réel relèvent d’extensions.

4.3 Hubs, contrôle et stocks

Le contrôle OCPV correspondra à la procédure métier validée. Les critères de qualité, les instruments de pesée et les responsabilités physiques devront être définis avec les responsables des hubs.

4.4 Catalogue, réservations et commandes

Le prix applicable, la durée de réservation, les frais et les conditions d’annulation seront présentés avant confirmation. Une modification ultérieure des paramètres ne réécrira pas l’historique d’une commande.

4.5 Paiements et traitement des exceptions

L’orientation proposée est un paiement direct au producteur sur mobile money via le prestataire retenu, une fois le lot contrôlé et publié par l’OCPV. Le parcours financier sera défini avant l’intégration : bénéficiaire producteur, part institutionnelle due à l’OCPV, confirmation, délais, frais, remboursement et conditions d’enlèvement. L’OCPV et CIACEMS valideront que les services du prestataire permettent ce fonctionnement et la traçabilité des deux composantes.

Les opérations de paiement, de remboursement et de sortie nécessitent une confirmation en ligne. Aucun mécanisme automatique de répartition de recettes institutionnelles n’est inclus dans le périmètre initial.

4.6 Information de marché, pilotage et analyse

Si l’API Info-Prix n’est pas disponible, un échange par fichiers pourra être validé comme solution transitoire. Il ne vaudra pas recette du connecteur API : la prestation restante sera identifiée et replanifiée par écrit.

L’expérimentation prédictive donnera lieu à un rapport même si les données sont insuffisantes ou si les modèles ne surpassent pas la référence simple. La mise en production de prévisions opérationnelles sera décidée selon ces résultats ; aucun taux de précision n’est promis avant l’évaluation.

4.7 Administration et traçabilité

5. Données et règles de cohérence

Le modèle de données couvrira les acteurs, identités de connexion, habilitations, territoires, hubs, produits, unités, lots, contrôles, stocks, réservations, commandes, règlements, sorties et observations économiques. Les données personnelles seront séparées des informations destinées à la publication.

Les invariants suivants seront vérifiés à la recette :

1. Un identifiant de lot reste stable pendant toute sa progression.
2. La quantité disponible ne devient jamais négative.
3. Une déclaration ou une notification reçue plusieurs fois ne produit pas plusieurs opérations équivalentes.
4. Un lot non contrôlé ne devient pas commandable.
5. Une confirmation de paiement possède une source vérifiable.
6. Une modification d’habilitation s’applique aux opérations suivantes, y compris via les API.
7. Une correction conserve l’historique utile à la traçabilité.

La reprise initiale comprendra un modèle de fichier, les règles de validation, un rapport d’erreurs, une répétition sur l’environnement de test et un bilan du chargement final. L’OCPV sera responsable de la validation métier des données remises et des rapprochements.

6. Exigences techniques et qualité de service

6.1 Architecture et exploitation

L’architecture V2.1 sera entièrement structurée en microservices métier déployables séparément. Chaque service backend disposera de son projet Django, de ses API Django Ninja, de sa configuration, de ses tests et de son image Docker. Les traitements asynchrones seront exécutés dans des conteneurs workers distincts des processus qui répondent aux requêtes HTTP.

6.1.1 Technologies retenues et rôle de chaque composant

Les versions exactes seront fixées dans le dossier de conception et les fichiers de dépendances, en retenant des versions maintenues et compatibles. Le socle Django privilégiera une branche à support long lorsqu’elle répond aux besoins. Chaque mise à jour suivra un cycle de vérification, de recette et de déploiement documenté.

6.1.2 Intérêt de Django, Django Ninja et Vue.js

Django apporte un cadre de développement structuré : modèles de données, ORM, migrations et administration intégrée. Ce socle facilite l’organisation des règles métier et la maintenance du backend dans la durée. L’administration Django sera réservée aux usages techniques autorisés ; les parcours des utilisateurs seront réalisés dans Vue.js. Présentation officielle de Django

Django fournit notamment des mécanismes de protection contre les injections SQL dans les usages couverts par son ORM, les requêtes intersites avec authentification par cookie lorsque la protection CSRF est activée, ainsi que des réglages de sécurisation HTTP. Leur efficacité dépend de leur configuration et des pratiques de développement ; les droits métier et la sécurité de la SPA seront vérifiés séparément. Sécurité Django

Django Ninja permet de décrire et valider les données des API à partir de schémas typés et de produire des contrats OpenAPI. Cela soutient les échanges entre microservices, l’intégration du frontend et la production documentaire. Les contrats générés seront complétés par les règles métier, les erreurs, les droits requis et les exemples d’usage. Documentation Django Ninja

Vue.js est retenu pour son organisation en composants et la réalisation d’une SPA, dont la navigation est assurée dans le navigateur. Les fonctions PWA et hors ligne seront développées explicitement et vérifiées sur les appareils retenus. Documentation Vue.js

6.1.3 Découpage des microservices et propriété des données

Chaque microservice possédera une base logique PostgreSQL et un compte d’accès limités à ses données. Une instance PostgreSQL peut initialement héberger plusieurs de ces bases, sans autoriser les autres services à lire ou modifier directement leurs tables. Les échanges passeront par des API authentifiées ou des événements documentés.

La réservation et la modification du stock resteront dans une même transaction du service lots–hubs–stocks. Les parcours traversant plusieurs services utiliseront des références stables, des opérations idempotentes, des délais et des compensations explicites. Les événements critiques seront enregistrés avec l’opération métier dans PostgreSQL avant leur transmission ; les envois non aboutis seront repris et rapprochés. Les tests couvriront les notifications dupliquées et les interruptions entre commande, réservation et paiement.

6.1.4 VPS locaux, orchestration et déploiement

Les composants auto-hébergés seront déployés en conteneurs Docker sur des VPS locaux, dont la localisation physique en Côte d’Ivoire sera confirmée avec l’hébergeur et l’OCPV. Le dossier de conception précisera le nombre de VPS, les ressources CPU/RAM/disque, les réseaux privés, la répartition des rôles et la capacité d’évolution. Les environnements de test et de production seront isolés.

Docker Swarm assurera l’orchestration ; Dokploy constituera l’interface de gestion des déploiements et des serveurs. Les images seront identifiées par version, conservées dans un registre et déployées après validation des tests. Les migrations PostgreSQL, les contrôles de santé et le retour à une version compatible seront documentés et exercés. Les réplicas et les limites de ressources seront définis service par service. Docker Swarm, architecture Dokploy

Les volumes PostgreSQL, les fichiers métier et les données persistantes du transport de tâches feront l’objet de règles de stockage et de sauvegarde distinctes des images. Leur placement et leur restauration seront définis explicitement : le redémarrage d’un conteneur sur un autre VPS ne suffit pas à rendre ses données disponibles. La topologie précisera aussi le nombre de nœuds de gestion Swarm et le maintien de leur quorum selon le niveau de continuité retenu.

L’hébergement local couvre les composants placés sous l’exploitation du projet. Auth0 et les prestataires de SMS ou de paiement restent des services externes ; les données échangées, leur localisation et leurs conditions de traitement seront documentées dans le dossier de sécurité.

6.2 Objectifs proposés et modalités de mesure

Ces objectifs supposent la souscription des moyens d’hébergement et de sauvegarde dimensionnés pour les atteindre. Les contrats de services tiers, leur disponibilité et leurs coûts seront examinés avant d’arrêter les engagements d’exploitation. Une haute disponibilité multisite constitue une extension à dimensionner séparément.

6.3 Reprise et refonte du code source E-Grenier V2

La reprise commencera par l’identification de la version remise, l’inventaire des modules et des dépendances, puis l’examen des règles métier, des interfaces, des accès et des procédures disponibles. CIACEMS reconstituera les éléments nécessaires à la compréhension du fonctionnement lorsque ceux-ci ne sont pas documentés.

Le plan de refonte précisera les composants conservés, restructurés ou remplacés, les raisons de ces choix, les effets sur les données et les interfaces et l’ordre des travaux. La réalisation portera sur les composants nécessaires au périmètre V2.1 défini dans le présent cahier des charges. Les décisions seront examinées avec l’OCPV avant les modifications correspondantes.

La reprise des règles et des données de la V2 conduira à une refonte du backend dans les microservices Django/Django Ninja et du web dans la SPA Vue.js. Le plan décrira les correspondances entre les fonctions reprises et les nouveaux services, les conversions de données et les contrats d’API associés.

6.4 Production et recette de la documentation

La documentation du code constituera une tâche de réalisation à part entière. Elle couvrira les modules, les règles métier, les traitements complexes, les dépendances et les décisions de conception. Elle sera complétée par le modèle de données, les contrats d’API et les procédures nécessaires à l’installation, aux tests, au déploiement, à l’exploitation et à la maintenance.

La réception technique inclura la vérification des exigences REF-01 à REF-04 et DOC-01 à DOC-03. La remise du code seul ne permettra pas de considérer les tâches de refonte et de documentation comme achevées.

6.5 Cache Redis et traitements asynchrones Celery

Le cache Redis accélérera les consultations qui le permettent. Chaque famille de clés aura une durée de vie, une règle d’invalidation et un périmètre d’accès définis. Les quantités commandables, les habilitations sensibles et les confirmations de paiement seront vérifiées auprès du service propriétaire ; une valeur en cache ne décidera pas seule d’une opération irréversible.

Le Redis du cache et celui qui transporte les tâches Celery seront des instances distinctes. Le premier pourra appliquer une politique d’éviction adaptée ; le second utilisera une persistance, une limite mémoire et une politique sans éviction automatique des messages. Des alertes seront prévues avant saturation. Politiques Redis, transport Redis de Celery

Les workers Celery seront déployés séparément des API et répartis en files selon les usages : notifications, échanges et imports, traitements financiers différés, analyses. Les délais maximaux, les nouvelles tentatives, les erreurs définitives et la reprise manuelle seront définis. Les tâches seront conçues pour éviter de répéter les effets d’une même demande ; un traitement financier conservera une référence et un état métier durables dans PostgreSQL. Une seule instance active de Celery Beat déclenchera les travaux planifiés. Règles de traitement des tâches Celery

6.6 Supervision et maintenance de l’infrastructure

Prometheus collectera les métriques des VPS, conteneurs, API et composants de données. Grafana présentera les tableaux de bord et Alertmanager acheminera les alertes aux interlocuteurs désignés. Le suivi couvrira la disponibilité, les erreurs, les temps de réponse, le disque, la mémoire, les connexions PostgreSQL, les files Celery et les échecs de sauvegarde. Principes de Prometheus

Grafana Alloy collectera les journaux destinés à Loki. Les services propageront un identifiant de corrélation pour reconstituer le parcours d’une demande entre API et workers. Les secrets, codes OTP et pièces sensibles seront exclus des journaux ; leurs accès et durées de conservation seront définis. Grafana Alloy, Grafana Loki

Les sauvegardes des bases, fichiers métier et configurations nécessaires à la reprise seront chiffrées et conservées sur un stockage distinct de l’hôte de production concerné. Des restaurations seront exercées selon les objectifs QUA-04. Les sauvegardes PostgreSQL incluront une stratégie documentée de cohérence et, si le niveau de reprise le nécessite, d’archivage des journaux de transactions. Sauvegarde et restauration PostgreSQL

6.7 Recette de l’architecture technique

Les résultats TEC-01 à TEC-09 seront joints au dossier de recette. La documentation L12 décrira la topologie, les API, les files Celery, les règles de cache, les responsabilités des bases et les procédures de surveillance et de reprise.

7. Sécurité et protection des données

La configuration Django de production fera l’objet d’une revue dédiée : mode de débogage désactivé, hôtes autorisés explicites, secrets protégés et HTTPS correctement pris en compte derrière Traefik. Les protections XSS de l’interface Vue.js, les contrôles de fichiers et la limitation des requêtes seront testés dans leur contexte d’usage. Configuration de production Django

Le dossier de conception précisera la localisation de l’hébergement et des services tiers, les accès et les éventuels transferts de données. Les formalités applicables seront identifiées avec les responsables compétents de l’OCPV avant la mise en service. La prestation comprend les vérifications de sécurité de CIACEMS ; un audit indépendant pourra être commandé séparément.

8. Gouvernance et calendrier proposé

Le planning de référence couvre 20 semaines de réalisation initiale, à compter de la réunion de lancement et de la mise à disposition des prérequis. Les travaux correspondant aux semaines 1 à 15 ont déjà été réalisés dans le cadre du projet Agrilink-CI, initialement prévu en lieu et place d’E-Grenier ; leurs livrables (cadrage, conception, parcours accès, lots, hubs, stocks, catalogue, intégrations et documentation associées) seront intégrés et consolidés dans E-Grenier V2.1. Il reste à mener la phase finale (semaines 16 à 20), dont la livraison du MVP est visée sous une semaine à la date de mise à jour du présent document. Un référent métier OCPV et un chef de projet CIACEMS assureront le suivi opérationnel. Les disponibilités des partenaires et les arbitrages seront suivis dans un registre partagé.

Une réunion opérationnelle hebdomadaire et un comité de pilotage mensuel sont proposés. Les remarques sur un livrable seront regroupées par l’OCPV, avec un objectif de retour sous cinq jours ouvrés. L’absence de retour ne vaut pas validation ; ses conséquences éventuelles sur le calendrier seront examinées conjointement.

9. Livrables et recette

La recette reposera sur les critères de chaque exigence et sur des scénarios complets : enrôlement producteur, accès alternatif, lot jusqu’à l’enlèvement avec publication OCPV, rupture réseau, concurrence sur le stock, paiement retardé ou dupliqué, accès hors périmètre et restauration. Elle comprendra également les tests de non-régression des composants repris et l’exercice de prise en main de la documentation prévu par DOC-03.

Une anomalie bloquante empêche un parcours essentiel ou porte atteinte aux données ou à la sécurité. Une anomalie majeure dégrade une fonction essentielle sans solution acceptable. Une anomalie mineure permet de poursuivre l’usage. La réception exigera l’absence d’anomalie bloquante ou majeure ouverte ; les réserves mineures éventuelles seront inscrites dans un procès-verbal avec une date de correction.

Les tests seront conduits en environnement dédié, puis confirmés sur le pilote selon un protocole convenu. Les paiements de production seront limités à des opérations autorisées par les parties. L’OCPV prononcera la recette métier ; CIACEMS fournira les preuves techniques.

10. Accompagnement en présentiel et formation

La présence terrain permettra de concevoir les parcours avec les utilisateurs et d’accompagner leur appropriation. La base proposée comprend 20 journées d’intervention sur site pendant la réalisation, puis une journée par mois pendant les 12 mois de maintenance initiale.

Les 20 journées de réalisation seront réparties entre ateliers et conception — 6 journées —, préparation et conduite du pilote — 6 journées —, formation — 4 journées — et démarrage et transfert — 4 journées. Une journée correspond à une journée de présence d’au moins un intervenant CIACEMS ; les rôles mobilisés varieront selon les travaux.

Les interventions courantes se dérouleront à Abidjan. La base logistique comprend deux missions régionales de trois jours au maximum pour deux intervenants, à programmer dans les 20 journées d’intervention. Les frais de déplacement et de séjour de ces missions sont intégrés à l’offre. Les salles, la mobilisation des bénéficiaires, leurs déplacements, leurs équipements et la connectivité des sites seront organisés par l’OCPV.

La formation couvrira jusqu’à 30 agents ou référents, répartis en groupes adaptés. Elle portera sur les fonctions métier, le traitement des exceptions, l’administration et l’assistance aux utilisateurs. Un exercice pratique permettra de vérifier l’autonomie sur les tâches principales. Les référents accompagneront ensuite les producteurs et acheteurs du pilote avec l’appui de CIACEMS.

11. Maintenance évolutive et continuité de l’accompagnement

11.1 Couverture initiale proposée

La période initiale de 12 mois comprendra l’assistance, la correction des anomalies du périmètre livré, les opérations préventives, le suivi des sauvegardes et les mises à jour de sécurité compatibles avec l’architecture retenue. Les anomalies de conformité seront corrigées sans consommation de l’enveloppe d’évolutions.

Une enveloppe de 24 jours-personnes d’évolution sur 12 mois est proposée pour les améliorations des fonctions livrées : champs, formulaires, règles, rapports et adaptations mineures d’interfaces. Elle comprend l’analyse, le développement, les vérifications, la documentation et la livraison. Une journée-personne correspond à sept heures de travail. Les journées de présence mensuelle sont distinctes de cette enveloppe.

Chaque évolution sera estimée avant réalisation et priorisée par l’OCPV. Le bilan mensuel indiquera les jours prévus, réalisés et restants. Les nouveaux modules et les extensions du §2.3 feront l’objet d’un chiffrage spécifique. Le reliquat éventuel sera examiné avant la fin de la période ; il ne prolongera pas automatiquement le contrat.

11.2 Support proposé

Le support sera ouvert du lundi au vendredi, de 8 h à 17 h, heure d’Abidjan, hors jours fériés. Les délais suivants se comptent pendant ces plages et concernent la prise en charge ; l’objectif de rétablissement sera précisé après diagnostic.

La supervision automatique fonctionnera en continu. Une astreinte humaine permanente n’est pas comprise dans le forfait initial. Un incident dépendant d’un tiers restera suivi par CIACEMS, avec des délais de résolution liés aux engagements de ce tiers.

11.3 Évolution à long terme

Une revue trimestrielle fixera les prochaines priorités à partir des usages, des incidents et des besoins des services. À partir du neuvième mois, l’OCPV et CIACEMS prépareront le programme de l’année suivante, les moyens de présence terrain et les ressources nécessaires.

L’accompagnement se poursuivra dans le cadre d’un contrat annuel de maintenance et d’évolution à convenir avant l’échéance. La durée financée, la capacité d’évolution, les déplacements et les frais tiers seront explicités pour chaque période. La documentation et le transfert de compétences assureront la continuité des connaissances.

12. Maîtrise du système et réversibilité

Les données métier seront placées sous la maîtrise de l’OCPV. Le code des développements spécifiques, les scripts, la documentation et les procédures d’exploitation seront remis selon les dispositions du contrat. Les composants préexistants et services tiers seront inventoriés avec leurs conditions d’utilisation.

La remise comprendra un export des données dans des formats documentés, un inventaire des comptes et abonnements, les accès d’administration convenus et une procédure de déploiement. Un atelier de transfert permettra aux référents désignés de réaliser les opérations courantes. Les conditions de propriété et de droits d’usage seront formalisées avant signature.

13. Prérequis et décisions de lancement

Une dépendance indisponible fera l’objet d’un constat précisant les fonctions concernées, les travaux réalisables et le jalon à replanifier. Le remplacement d’un livrable par une solution transitoire nécessitera un accord écrit sur son périmètre et sa recette.

14. Validation du cahier des charges

La version retenue précisera les exigences incluses, les extensions différées, les hypothèses de dimensionnement et les engagements de service. Elle sera rattachée à l’offre technique et financière et au calendrier approuvés.

La validation portera sur une V2.1 utilisable, vérifiable et accompagnée dans la durée, avec une trajectoire d’évolution partagée entre l’OCPV et CIACEMS.