Étude comparative — E-Grenier V2.0 et E-Grenier V2.1

Modernisation de la commercialisation vivrière et convergence avec OCPV Info-Prix

1. Résumé exécutif

L’évolution vers E-Grenier V2.1 est justifiée par la nécessité de relier la promesse commerciale à une marchandise contrôlée, à une transaction vérifiable et à une information de marché exploitable. Cette transformation dépasse la rénovation des écrans : elle organise une chaîne de responsabilité entre le producteur, les agents de l’OCPV, l’acheteur et les services de pilotage économique.

Les TDR SAFAF d’octobre 2025 rapportent cinq faiblesses majeures d’E-Grenier : absence de paiement électronique intégré, sécurité insuffisante, API incomplètes ou instables, difficultés d’usage et architecture monolithique difficile à faire évoluer. Ces constats constituent une justification documentaire de la modernisation ; ils ne remplacent pas un audit actualisé de la version effectivement en service en septembre 2026. [S1, §1]

À ces difficultés s’ajoute une absence totale de documentation du code source de la V2 produit par l’ancien prestataire d’E-Grenier, selon le constat communiqué par CIACEMS. Cette lacune complique la compréhension du fonctionnement interne, la maintenance et le transfert de compétences. La V2.1 intégrera donc la documentation du code et son actualisation à chaque livraison parmi les exigences de pérennité du système. [O3 ; P]

La cible V2.1 est conçue à partir des besoins de l’OCPV et des nouveaux documents de cadrage. Elle apporte cinq changements structurants :

1. Un accès adapté et un enrôlement maîtrisé. L’inscription libre producteur de la V2.0 est remplacée par un espace d’enrôlement contrôlé par l’OCPV (KYC, validation, génération des accès). Une entrée web/PWA par lien, des parcours courts par profil et une trajectoire multicanale réduisent les obstacles d’installation. L’ajout d’Auth0 diversifie les moyens de connexion, limite la dépendance aux SMS OTP et propose un accès alternatif en cas d’indisponibilité du service SMS. [O2 ; P]
2. Un catalogue adossé au contrôle physique. Le lot déclaré devient commandable après réception, pesée et contrôle au hub. L’OCPV dispose d’une preuve opérationnelle de disponibilité et d’une chaîne de traçabilité.
3. Des flux financiers explicitement séparés. Le prix de la marchandise et les recettes institutionnelles ont des bénéficiaires, des statuts et des rapprochements distincts. Le paiement direct au producteur constitue l’orientation proposée ; sa confirmation et les litiges doivent rester encadrés.
4. Un SIM alimenté par les opérations. Les données des lots et des transactions complètent les enquêtes Info-Prix pour suivre les stocks, les coûts de transport et les flux, puis développer des analyses prédictives évaluables. [P]
5. Un accompagnement de proximité dans la durée. L’équipe CIACEMS accompagnera l’OCPV en présentiel pendant la conception, le déploiement et l’exploitation. Les retours des agents et des utilisateurs alimenteront une maintenance évolutive organisée avec l’OCPV, pour adapter le système aux pratiques et aux besoins futurs. [O2]

L’avantage attendu est organisationnel autant que technologique. Une information contrôlée plus tôt doit réduire les vérifications répétées, les ventes de stocks inexistants et les rapprochements manuels. Des parcours d’accès adaptés doivent améliorer l’adoption. Leur effet financier devra être mesuré par un pilote et un coût total de possession, plutôt que déduit du seul choix d’un fournisseur d’identité ou d’un langage.

Le cadrage doit préciser la confirmation des paiements et les conditions de disponibilité des différents canaux. Les règles relatives au séquestre et au délai de confirmation devront être arrêtées dans le nouveau cahier des charges. L’offre Info-Prix V2.0 de DAT prévoit déjà web, iOS/Android, collecte hors ligne, API sécurisées et tableaux de bord. La différenciation V2.1 porte principalement sur leur convergence avec les opérations de commercialisation, le lot contrôlé et l’anticipation économique. [S3, III ; P]

Recommandation : retenir V2.1 comme projet de modernisation sur mesure, associant réalisation progressive et accompagnement durable de l’OCPV. Les fonctionnalités, les critères de recette et le dispositif de maintenance seront formalisés dans le nouveau cahier des charges. La démarche s’inscrit dans les objectifs du programme E-Grenier/SAFAF et de convergence avec Info-Prix. [O2 ; P]

2. Périmètre et méthode de comparaison

2.1 Trois objets à ne pas confondre

La dénomination « E-Grenier V2.1 » est utilisée comme convention de travail demandée pour cette étude. Le corpus retenu ne constitue pas un acte unique validant ce numéro de version et tout son périmètre.

2.2 Niveau de preuve

Les renvois S1 à S3 identifient les trois références documentaires présentées en annexe, citées par leur titre. O1 désigne les observations initiales fournies dans la demande ; O2, les orientations actualisées pour V2.1 et l’accompagnement de l’OCPV ; O3, le constat communiqué par CIACEMS sur l’absence de documentation du code source V2 ; P, une orientation ou une proposition de mise en œuvre portée par cette étude. Les références T1 à T3 documentent les capacités web et les moyens de connexion proposés.

Le corpus établit les lacunes rapportées par les TDR, les ambitions fonctionnelles et les divergences de conception. Il ne fournit pas de factures SMS, de mesures de disponibilité comparées, de statistiques de fraude, de procès-verbal complet de recette V2.1 ou de budget consolidé permettant de certifier une supériorité financière déjà réalisée.

Les éléments suivants sont donc traités comme observations terrain à corroborer, et non comme conclusions d’un audit indépendant : Flutter/Dart pour l’application E-Grenier observée ; diffusion Android exclusivement par APK depuis le site OCPV ; présentation simultanée des trois profils ; OTP systématique ; auto-publication des produits ; circuit actuel de wallet et de retrait. Les TDR confirment l’existence d’une APK auditée et plusieurs faiblesses générales, sans détailler tous ces comportements. [O1 ; S1, §1]

Cette étude consolide les orientations fonctionnelles, techniques et d’accompagnement de la V2.1. Elle servira de base à la rédaction du nouveau cahier des charges et à la validation des exigences avec l’OCPV.

3. Comparatif architectural et accessibilité

3.1 Matrice de synthèse

3.2 PWA, applications mobiles et installation

Une PWA permet de proposer une application web accessible par URL et, selon les plateformes, installable. Les capacités hors ligne nécessitent une conception et une mise en cache explicites. L’accès par lien peut précéder l’installation, mais une PWA ne garantit ni toutes les fonctions natives ni un fonctionnement intégral sans réseau. Documentation MDN sur les PWA [T1]

Le bénéfice V2.1 attendu est concret : un producteur recevant un lien peut commencer son parcours sans rechercher puis installer un fichier APK. Le catalogue et les services administratifs deviennent accessibles depuis les terminaux compatibles. Les parcours doivent rester utilisables sur petit écran, avec des messages courts et une consommation de données limitée. [O1 ; P]

Les applications distribuées sur les stores complètent l’accès web pour les usages mobiles. Les TDR Info-Prix V2 et l’offre DAT prévoient iOS et Android ; la cible E-Grenier V2.1 reprend cette ouverture multiplateforme après l’entrée PWA. Les applications mobiles Android et iOS seront développées avec Flutter, en langage Dart, et utiliseront les API Django Ninja du backend. La friction observée en V2.0 provient du mode de distribution et de l’expérience proposée ; elle ne démontre pas une faiblesse intrinsèque de Flutter. [S2, §3.3 ; S3, III.5.3 ; O1 ; O2]

3.3 Inclusion effective et assistance

Le Voice-to-JSON doit restituer à l’utilisateur le produit, la quantité, l’unité et le lieu compris, puis obtenir sa confirmation. Une confusion entre kilogrammes et tonnes ne doit pas déclencher automatiquement une collecte. L’efficacité de ce canal se mesure par le taux de demandes correctement comprises et confirmées, par langue et en conditions de terrain. [P]

La création de tous les canaux simultanément augmenterait le coût et les dépendances. Le déploiement proposé commence par les parcours web et assistés, puis ajoute les canaux en fonction des résultats d’usage et des contrats opérateurs. Leur inclusion dans la cible ne vaut pas disponibilité immédiate. [P]

3.4 Architecture évolutive et exploitation

La cible retient une architecture intégralement organisée en microservices métier, avec des responsabilités et des contrats d’API explicites. Les services couvriront les acteurs et habilitations, les lots–hubs–stocks, les commandes, les paiements, le SIM et les notifications. Chaque service sera déployable séparément et propriétaire de ses données. Les trois nœuds Producteur–Hub–Marché décrivent le parcours métier ; le découpage logiciel répond aux responsabilités opérationnelles de ce parcours. [O2 ; P]

Les choix arrêtés pour la V2.1 sont Python/Django pour le backend, Django Ninja pour les API et Vue.js pour la SPA web, avec les fonctions PWA prévues. PostgreSQL conservera les données métier, Redis assurera le cache initial et Celery exécutera les tâches asynchrones dans des workers dédiés. Le transport des tâches utilisera une instance Redis distincte du cache. [O2 ; P]

Les composants auto-hébergés seront conteneurisés avec Docker et déployés sur des VPS locaux, sous Docker Swarm, avec Dokploy pour le pilotage des déploiements. Prometheus, Grafana et Alertmanager assureront la supervision et les alertes ; Loki et Alloy centraliseront les journaux. Le dimensionnement des VPS, la localisation physique de l’hébergement, la sécurité des accès et les procédures de restauration seront précisés dans le dossier de conception. [O2 ; P]

La conception prévoira une disponibilité progressive, appuyée sur la supervision, la redondance des composants critiques, les sauvegardes et les procédures de restauration. Les niveaux de service seront dimensionnés selon les usages, puis inscrits dans le cahier des charges et vérifiés par des exercices de reprise. [P]

3.5 Documentation du code et autonomie de maintenance

CIACEMS signale une absence totale de documentation du code source de la V2 produit par l’ancien prestataire d’E-Grenier. Ce constat est repris comme une observation communiquée par CIACEMS sur le code concerné. [O3]

Une équipe chargée de maintenir un code non documenté doit reconstituer les règles de gestion, les dépendances et les choix de conception à partir de l’implémentation. Cette situation augmente l’effort de prise en main et peut allonger les délais de correction, favoriser les régressions et renforcer la dépendance aux développeurs qui connaissent déjà le système. La seule remise du code source ne suffit donc pas à assurer son appropriation durable par l’OCPV. [P]

Pour la V2.1, CIACEMS prévoit une documentation versionnée avec le code : description des modules et des règles métier, explication des traitements complexes, modèle de données, contrats d’API, instructions d’installation, de test et de déploiement, ainsi que procédures d’exploitation et de reprise. Toute évolution devra mettre à jour les documents concernés. La recette vérifiera qu’un intervenant technique habilité peut installer la solution en environnement de test et exécuter les vérifications prévues à partir des éléments remis. [P]

4. Comparatif fonctionnel et expérience utilisateur

4.1 De l’annonce au lot contrôlé

Le parcours V2.0 décrit permet au producteur de s’inscrire librement et de publier une offre avant contrôle physique de l’OCPV. La récolte peut devenir visible ou connue des agents sans publication institutionnelle sur la marketplace, ce qui affaiblit la chaîne de responsabilité. Cette simplicité initiale reporte la vérification de disponibilité sur les étapes suivantes : l’acheteur peut manifester son intention avant que la quantité et la qualité aient été confirmées. La fréquence réelle des incidents liés à ce parcours reste à mesurer. [O1]

La V2.1 proposée donne un identifiant stable au lot dès sa déclaration et conserve cet objet pendant toute sa progression :

Producteur : déclaration → préparation de la collecte → Hub OCPV : réception, pesée et qualité → Marché : réservation et transaction → confirmation et bon d’enlèvement. [détail de parcours proposé P]

La traçabilité repose sur une référence de lot conservée entre les étapes. Chaque remise et chaque contrôle doivent enregistrer l’acteur, la date, le lieu et le résultat. Les modalités de preuve et les supports utilisables seront définis dans le nouveau cahier des charges et testés avec les agents. [P]

Un lot non contrôlé peut éventuellement être affiché comme « annoncé » si cette fonction est retenue ; il ne doit pas être présenté comme disponible à l’achat. Cette distinction permet de séparer la préannonce d’une récolte et la disponibilité commerciale d’un lot contrôlé. [P]

4.2 Bénéfice et contrepartie du passage au hub

Le contrôle préalable permet de déplacer la vérification avant la commande et de réduire les ressaisies. Toutefois, un lot contrôlé peut ensuite être réservé, retiré ou se dégrader : la gestion des stocks, des réservations concurrentes et de la péremption reste nécessaire. « Certifié » désigne ici le contrôle OCPV défini par la procédure ; aucune certification sanitaire ou qualité externe ne peut être présumée. [P]

Le passage obligatoire au hub crée aussi des coûts : transport, manutention, stockage, capacité de pesage et présence des agents. Sa valeur doit être évaluée face aux pertes évitées, aux litiges et au service rendu. Pour les petits producteurs, un éventuel seuil logistique devra être étudié avec des possibilités de groupage, puis défini avec l’OCPV selon les capacités de collecte et les besoins du terrain. [P]

4.3 Inscription, enrôlement et authentification compréhensibles

En V2.0, l’écran d’inscription est ouvert à tous : un utilisateur peut se créer un compte producteur sans contrôle préalable de l’OCPV, ce qui permet des profils erronés ou frauduleux.

En V2.1, le candidat producteur passe par un espace d’enrôlement : dépôt de demande, pièces KYC, instruction et décision par l’OCPV, puis génération des accès en cas de validation. Les acheteurs et autres profils conservent des parcours adaptés à leur intention. L’accès technique au compte et la validation métier par l’OCPV restent deux états distincts. [O1 ; P]

Une fois enrôlé, le producteur déclare ses récoltes reçues et contrôlées ; il ne publie pas lui-même sur la marketplace. L’OCPV vérifie et publie l’offre. L’acheteur intéressé paie directement le producteur sur mobile money, le produit ayant été vérifié par l’OCPV ; la part due à l’OCPV (taxe ou recette institutionnelle) est identifiée et tracée à part du prix de la marchandise. [P]

L’interface de saisie d’un OTP doit se concentrer sur le code, le destinataire masqué, le délai de renvoi et une option compréhensible de correction du numéro. Les termes techniques d’identité et les actions de redémarrage ambiguës ne doivent pas détourner l’utilisateur de la tâche. Le coût de SMS dépend également des renvois, des erreurs et des sessions inutilement interrompues. [O1 ; P]

Orientation V2.1 : ajouter Auth0 comme service de gestion des identités et de fédération des connexions, en complément du parcours SMS OTP. Les utilisateurs pourront disposer de moyens d’accès adaptés à leur équipement et à leurs habitudes. Les exigences d’authentification renforcée seront précisées par profil et par opération dans le nouveau cahier des charges, avec des parcours testés auprès des utilisateurs. [O2 ; S1, §2.2 ; P]

4.4 Convergence avec Info-Prix et SIM proactif

Info-Prix ne peut être réduit à un système entièrement manuel : les TDR indiquent que sa première version a déjà raccourci les délais de collecte, d’analyse et de diffusion. Sa V2.0 prévoit stocks, transport, flux, personnalisation, alertes et applications web et mobiles. L’offre DAT décrit également la collecte hors ligne, la validation des relevés, les exports et la cartographie. [S2, §1.1–3 ; S3, III.1–2]

L’apport spécifique recherché avec V2.1 est le rapprochement de ces enquêtes avec les données opérationnelles du lot : déclaration, quantité reçue, stock contrôlé, réservation, vente et sortie. Le SIM conserve les observations des marchés extérieurs à la plateforme ; celles-ci ne doivent pas être remplacées par les seules transactions E-Grenier, qui peuvent ne pas représenter tout le marché national. [P]

Une plateforme unifiée peut conserver des modules distincts. Elle suppose d’abord des références communes pour les produits, unités, zones, marchés et acteurs, des règles de qualité partagées et une provenance explicite des données. Elle n’exige pas que tous les services écrivent dans une même base physique. [P]

Prophet et Isolation Forest constituent des pistes techniques à évaluer lors de la conception. Le choix des modèles sera fondé sur leurs résultats sur les données disponibles. Les résultats doivent comporter une mesure d’erreur, une indication d’incertitude et un suivi des fausses alertes. Les stocks déclarés, contrôlés, réservés et vendus doivent être séparés pour éviter une surestimation de l’abondance. [P]

5. Modèle financier et sécurisation des transactions

5.1 Diversification des moyens de connexion et continuité d’accès

La V2.1 prévoit l’ajout d’Auth0 pour diversifier les moyens d’authentification en complément des codes OTP reçus par SMS. L’objectif est de laisser aux utilisateurs plusieurs possibilités de connexion, de réduire la dépendance à un canal unique et de permettre un accès alternatif lorsque le prestataire SMS rencontre une indisponibilité. [O2]

Auth0 assure la gestion des identités et peut réunir plusieurs connexions, notamment des comptes applicatifs et des fournisseurs d’identité externes. La fédération d’identités permet de proposer des connexions telles que Google ou Apple, selon les options retenues pour le projet. Documentation Auth0 — fournisseurs d’identité, connexions sociales [T2–T3]

Cette diversification poursuit deux bénéfices complémentaires :

• Maîtrise des coûts à grande échelle : les connexions réalisées par un moyen sans SMS peuvent diminuer le volume de codes OTP à envoyer, et donc réduire éventuellement la dépense de messagerie.
• Continuité d’accès : en cas de panne ou de retard du service SMS, un utilisateur disposant d’un autre moyen de connexion déjà configuré peut continuer à accéder à son compte.

Le parcours devra proposer clairement ces alternatives et permettre leur préparation avant un incident, tout en conservant le même compte métier et les mêmes droits. Le SMS OTP restera disponible pour les personnes qui le privilégient. La redondance recherchée concerne les moyens de connexion : son efficacité sera vérifiée en simulant une indisponibilité du service SMS et en testant un accès alternatif sans dépendance à ce service. [O2 ; spécification proposée P]

La conception et la recette préciseront les méthodes retenues, leur disponibilité, le rattachement sécurisé au compte et les règles de récupération. La supervision couvrira le service d’identité et les canaux de connexion. [P]

5.2 Coût total de possession et investissements

La comparaison doit porter sur un horizon commun, proposé ici à trois ans, et sur un service rendu comparable :

TCO sur 36 mois = investissement initial + migration + formation + somme des coûts mensuels d’exploitation et de support + renouvellements et réversibilité.

Les économies budgétaires de l’OCPV, les revenus nets des producteurs et les bénéfices économiques collectifs doivent être évalués séparément. Des gains de temps ou des pertes évitées ne deviennent pas automatiquement une recette budgétaire. De même, une refonte fonctionnelle plus large peut être justifiée sans être moins chère qu’une maintenance limitée. [P]

Les durées documentaires ne permettent pas de déduire un prix V2.1 : les TDR Info-Prix prévoient environ 50 jours ouvrés étalés sur douze semaines ; l’offre DAT annonce 222 jours-personnes et dix semaines. Ce sont des mesures et périmètres à rapprocher, pas des montants financiers directement comparables. Elles ne constituent pas un calendrier garanti pour l’ensemble commercialisation, paiement, inclusion et IA de V2.1. [S2, §4–5 ; S3, IV.4–6]

5.3 Paiements intégrés et fluidité du parcours

Le circuit V2.0 décrit par le porteur comporte une vérification de disponibilité puis un wallet ou séquestre et une demande de retrait. Il suggère des attentes et des opérations supplémentaires. Le corpus ne permet toutefois pas de certifier que ce circuit est actuellement opérationnel : les TDR identifient l’absence d’intégration des paiements et demandent un escrow futur. [O1 ; S1, §1 et §2.2]

La cible V2.1 retient le paiement direct au producteur et la séparation des flux commerciaux et institutionnels. Le contrôle du lot au hub intervient avant sa mise en vente, ce qui permet de prendre la commande sur une disponibilité déjà contrôlée. L’intégration des paiements doit ensuite réduire les ressaisies, suivre le règlement et rendre son état compréhensible pour les parties. [O1 ; P]

Le nouveau cahier des charges précisera les moyens de paiement, la confirmation du règlement, les délais, les frais et le traitement des échecs. Un délai de confirmation de 24 heures pourra être étudié comme hypothèse de travail, à valider avec l’OCPV selon les usages et les contraintes opérationnelles. Les délais effectifs et les possibilités d’automatisation seront vérifiés avec les prestataires retenus. [P]

5.4 Protection des parties et traitement des exceptions

Le paiement direct doit s’accompagner de règles explicites de réservation, d’annulation, de remboursement et de non-conformité. Le contrôle du stock au hub réduit un risque ; il ne supprime pas celui d’un paiement erroné ou d’un désaccord. [P]

La V2.1 devra traiter les paiements incomplets, les bénéficiaires incorrects, les notifications reçues plusieurs fois, les réservations concurrentes et les interruptions du réseau. Chaque transaction conservera une référence permettant de rapprocher la commande et les informations confirmées par le prestataire de paiement. Les cas sans confirmation devront suivre une procédure d’exception tracée. [S1, §2.2 ; exigences proposées P]

6. Sécurité, gouvernance et alignement avec les objectifs SAFAF

6.1 Sécurité évaluée sur des contrôles effectifs

Le progrès visé consiste à centraliser les identités, appliquer les droits dans le backend, séparer les périmètres territoriaux et conserver des traces de décision. Un agent ne doit pas pouvoir approuver un lot hors de son hub ; un administrateur régional ne doit pas obtenir des droits nationaux par modification d’un formulaire. Ces règles doivent être vérifiées indépendamment de l’interface. [P]

La cible inclut aussi protection des échanges, gestion des secrets, sauvegardes, surveillance et procédures de révocation. La présence d’un journal ou de pgAudit ne garantit pas à elle seule une trace impossible à altérer : la conservation indépendante, les droits d’administration et les mécanismes de contrôle d’intégrité doivent être définis. La traçabilité sera définie par des exigences vérifiables de conservation, d’accès et de contrôle d’intégrité. [P]

L’OTP établit la maîtrise d’un canal à un instant donné ; il ne constitue pas à lui seul une vérification complète de l’identité ni une procédure KYC/AML. Le compte institutionnel, le compte utilisateur et les obligations du prestataire de paiement doivent conserver des finalités distinctes. Le traitement des données vocales et des pièces d’identité exige également une politique explicite de collecte, d’accès et de conservation. [S1, §2.2 ; P]

6.2 Résultats démontrables pour le programme

Le tableau suivant traduit les objectifs présents dans le corpus en preuves proposées. Il ne remplace pas les conditions particulières de la convention de financement ou les validations de l’UE.

La V2.1 organisera la maîtrise du système par l’OCPV : propriété des données, accès au code et à la documentation, conditions de maintenance, transfert de compétences et réversibilité seront formalisés. L’accompagnement en présentiel facilitera leur appropriation par les équipes responsables de l’exploitation. [S3, V.2 ; O2 ; P]

7. Arbitrages et trajectoire de réalisation

7.1 Décisions à préciser dans le nouveau cahier des charges

7.2 Base de rédaction du cahier des charges V2.1

La présente étude consolide les exigences issues des TDR, les éléments de l’offre technique Info-Prix et les orientations proposées pour la V2.1. Elle constitue la base de rédaction du nouveau cahier des charges, qui précisera les fonctionnalités, les règles de gestion et les décisions de conception, notamment la diversification des moyens de connexion avec Auth0 et l’accompagnement durable en présentiel.

Le nouveau cahier des charges sera rédigé à l’issue de cette étape de présentation et de consolidation de la V2.1. Il traduira les orientations retenues en exigences fonctionnelles et techniques, règles de gestion, livrables et critères de recette. Il précisera également l’organisation de la présence terrain, la maintenance évolutive, les engagements de service et le transfert de compétences. [O2 ; P]

7.3 Calendrier de référence et reprise Agrilink-CI

Le planning documentaire de référence couvre 20 semaines de réalisation initiale. Les semaines 1 à 15 ont déjà été réalisées dans le cadre du projet Agrilink-CI, initialement prévu en lieu et place d’E-Grenier ; leurs livrables seront intégrés dans E-Grenier V2.1. Il reste la phase finale (semaines 16 à 20), avec une livraison du MVP 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 assurent le suivi opérationnel. [P]

7.4 Livraison proposée par résultats

L’initialisation du système reposera sur les référentiels et données retenus avec l’OCPV. Si une reprise de données est nécessaire, son périmètre, sa qualité et ses correspondances seront définis lors du cadrage. Le déploiement commencera sur un périmètre pilote avec les agents, puis sera étendu après validation des parcours et des conditions d’exploitation. [P]

7.5 Indicateurs proposés de recette et de bénéfice

Les valeurs cibles, hormis les invariants métier explicitement adoptés, seront fixées après mesure de référence. Les résultats V2.0 et V2.1 devront être comparés sur des territoires, produits et périodes comparables pour ne pas attribuer au logiciel un effet de saisonnalité ou de sélection du pilote. [P]

8. Accompagnement en présentiel et maintenance évolutive à long terme

8.1 Une équipe aux côtés de l’OCPV

L’équipe CIACEMS accompagnera l’OCPV en présentiel tout au long du projet et dans la durée pendant l’exploitation. Cette proximité permettra d’observer les pratiques, de concevoir les parcours avec les agents, d’accompagner les premières utilisations et de faire évoluer le système au rythme des besoins de l’Office. Elle constitue un élément central de la proposition V2.1. [O2]

Les interventions associeront les services centraux, les antennes, les hubs et des représentants des utilisateurs selon les besoins. Elles serviront à identifier les difficultés concrètes : déclaration d’un lot, contrôle, publication, suivi d’un paiement ou exploitation des données de marché. Chaque difficulté sera traduite en action de formation, en correction ou en évolution fonctionnelle. [P]

L’organisation précisera les référents OCPV et CIACEMS, les lieux d’intervention, la fréquence de présence et les modalités d’assistance entre les visites. Ces dispositions seront fixées dans le cahier des charges et le cadre contractuel de l’accompagnement. [P]

8.2 Un cycle d’évolution piloté avec l’OCPV

La maintenance évolutive suivra un cycle partagé, depuis le besoin exprimé jusqu’à la vérification de son utilité après livraison :

Des points opérationnels réguliers suivront les demandes en cours. Un comité de suivi OCPV–CIACEMS arbitrera les priorités, les moyens et les prochaines livraisons. Une revue périodique de la feuille de route permettra d’intégrer de nouveaux territoires, filières, partenaires ou besoins de pilotage. Les cadences seront convenues avec l’OCPV. [P]

8.3 Maintenir la fiabilité tout en faisant évoluer les fonctions

Le budget récurrent distinguera l’exploitation, l’assistance, la présence terrain et la capacité consacrée aux évolutions. Le cahier des charges précisera le périmètre de maintenance, les niveaux de priorité, les délais de prise en charge et les modalités d’estimation et de validation des demandes supplémentaires. [P]

8.4 Transfert de compétences et pérennité

La formation accompagnera chaque étape : prise en main des parcours, montée en compétence des référents et actualisation des supports lors des nouvelles versions. Les agents disposeront de guides adaptés à leurs tâches et de procédures pour signaler une difficulté, suivre son traitement et participer à la recette. [O2 ; P]

Le code source, la documentation technique, les procédures d’exploitation et l’historique des versions seront tenus à jour et accessibles à l’OCPV selon les dispositions convenues. Le dispositif prévoira la continuité des connaissances au sein de l’équipe, la transmission aux référents de l’Office et les conditions de reprise du service. [S2, §3.3–3.4 ; P]

La documentation du code fera partie des livrables de chaque version et des vérifications de recette. Les séances de transfert expliqueront les principaux modules, les règles métier et les procédures de maintenance afin de rendre les éléments remis utilisables par les référents techniques. [P]

Le suivi portera sur la résolution des incidents, la réalisation des évolutions convenues, l’usage des fonctions livrées, l’autonomie des agents et leur satisfaction. La pérennité recherchée repose sur un système sur mesure, entretenu et amélioré avec les personnes qui l’utilisent. [O2 ; P]

9. Conclusion pour la Direction Générale et les partenaires

E-Grenier V2.1 offre une trajectoire plus complète de maîtrise de la commercialisation vivrière : elle relie la déclaration, le contrôle physique, le catalogue, les flux financiers et l’information économique. Cette cohérence constitue le principal argument en faveur de la refonte.

La modernisation des interfaces et la diversification des connexions avec Auth0 peuvent élargir l’adoption et limiter la dépendance au service SMS OTP. Le contrôle au hub peut améliorer la fiabilité du catalogue. La séparation des flux peut clarifier les responsabilités financières. Le rapprochement avec Info-Prix peut renforcer les données utiles aux acteurs et au pilotage public. Chaque bénéfice est associé dans cette étude à ses conditions de réalisation et à une preuve mesurable.

L’accompagnement de CIACEMS en présentiel donnera à l’OCPV un interlocuteur de proximité pour construire les parcours, former les agents et faire évoluer les fonctions. La maintenance évolutive prolongera ce travail après la mise en service, avec des priorités partagées, des livraisons vérifiées et un transfert continu de compétences.

La décision proposée est de retenir l’orientation V2.1 et son dispositif d’accompagnement durable, puis de rédiger le nouveau cahier des charges avec l’OCPV. Celui-ci formalisera le système à réaliser, les étapes de déploiement et les moyens de le maintenir et de le faire évoluer à long terme.

Annexe A — Sources et traçabilité

Corpus documentaire transmis

Éléments complémentaires et références techniques

• O1 — Observations et cible communiquées par le porteur du projet : consignes initiales jointes à la demande, notamment APK/Flutter, parcours à trois profils, OTP, publication autonome, wallet et cible PWA/paiements intégrés. Leur statut d’observation ou de proposition est conservé dans l’étude.
• O2 — Orientations actualisées du porteur du projet : conception de la V2.1 sur la nouvelle base documentaire ; ajout d’Auth0 pour diversifier les connexions, réduire éventuellement la dépense de SMS à grande échelle et prévoir une alternative en cas d’indisponibilité SMS ; accompagnement durable en présentiel et maintenance évolutive ; refonte Python/Django avec API Django Ninja, SPA Vue.js, applications Android/iOS en Flutter avec Dart, PostgreSQL, Redis et Celery ; architecture en microservices conteneurisés et orchestrés sur VPS locaux, avec Dokploy et supervision.
• O3 — Constat communiqué par CIACEMS sur le code source E-Grenier V2 : absence totale de documentation du code produit par l’ancien prestataire. Observation fournie pour cette révision de l’étude, distincte des constats d’audit rapportés par les TDR.
• T2 — Auth0 : Identity Providers, consulté pour cette révision.
• T3 — Auth0 : Social Identity Providers, consulté pour cette révision.
• T1 — MDN : Progressive web apps, consulté le 18 septembre 2026.

Pièces à obtenir pour transformer l’étude en dossier de décision chiffré

Rapport d’audit complet et version E-Grenier auditée ; démonstration des parcours actuels ; factures et statistiques SMS ; volumétrie utilisateurs et transactions ; conventions et capacités des prestataires de paiement ; inventaire des référentiels et données ; coûts de fonctionnement des hubs ; budget et engagements de maintenance ; procès-verbaux de validation et conditions de financement applicables.