Une plateforme hybride Odoo 16 + Django pour la gestion de bourses d'études autochtones, des inscriptions, de la facturation et de la documentation. Deux stacks sur une seule base Postgres, avec les documents dans S3 derrière des URL de téléchargement S3 présignées de courte durée.
Avataq est une plateforme hybride Odoo 16 + Django pour la gestion de bourses d'études autochtones, des inscriptions et de la documentation. Odoo porte la logique métier — étudiants, écoles, sessions, années scolaires, dossiers d'inscription, feuilles de calcul pour la facturation, réconciliation. Une application Django séparée sert le côté explorateur de documents : accès en lecture seule aux pièces téléchargées avec des URL S3 présignées de soixante secondes, verrouillées par rôle.
Nous l'avons bâtie de bout en bout. Deux applications qui partagent une seule base PostgreSQL et communiquent en REST. Les documents vivent dans AWS S3 sous des clés déterministes (`{status_no}/{scholar_year}/{slug}.{ext}`) — la clé encode le contexte. Les identifiants vivent dans `ir.config_parameter`, pas dans le code. Un mixin abstrait `AvataqDocumentS3Sync` donne à n'importe quel modèle Odoo la capacité d'upload gratuitement ; un endpoint `index_document` côté Django upsert l'index depuis un POST verrouillé par `X-API-Key`.
Sortir l'explorateur de documents d'Odoo n'était pas un accident. Odoo est excellent pour modéliser le métier — étudiants, sessions, feuilles de calcul, réconciliation. Il est moins bon comme visualiseur rapide et ciblé pour des milliers d'enregistrements binaires avec accès par rôle. Alors l'explorateur vit dans Django, lit la même base, demande à S3 des URL présignées de courte durée, et ne garde jamais les documents en mémoire.
Nous sommes sur cette plateforme depuis début 2023. La cadence est régulière — de nouveaux flux à mesure que les workflows de bourses s'étendent, des affinements de flux documentaires à mesure que la cohorte grandit, des sauvegardes S3 nocturnes.
Addon Odoo principal — étudiants, inscriptions, sessions, écoles, feuilles de calcul, réconciliation, modèles de mail, upload de documents S3, sync Django.
Portail public et templates de site.
Personnalisation auth et inscription.
Sauvegardes planifiées de la base vers S3.
Visualiseur en lecture seule sur la même base Postgres. Verrouillé par permission `documents.can_view_documents`. Génère des URL S3 présignées à la demande.
Mixin Odoo abstrait — héritez et obtenez upload S3 + notification d'index Django gratuitement. Utilisé sur trois modèles uploaders.
Odoo POST les métadonnées de document vers Django `/api/index/` après chaque upload réussi, verrouillé par `X-API-Key`. Django upsert la ligne d'index ; n'écrit jamais en retour.
docker-compose pour db / odoo / django ; env conda partagé `avataq_env` sur les deux stacks ; un seul `deploy.sh` pour les rollouts en production.
Sortir l'explorateur de documents d'Odoo n'était pas un accident. Odoo est excellent pour modéliser le métier ; moins bon comme visualiseur binaire rapide avec accès par rôle. Alors l'explorateur vit dans Django, lit la même Postgres, demande à S3 des URL présignées de courte durée, et ne garde jamais les documents en mémoire.
Trois modèles Odoo avaient besoin du même comportement d'upload S3. Nous avons écrit `AvataqDocumentS3Sync` comme mixin abstrait — héritez et obtenez génération de clé, upload S3 et notification d'index côté Django gratuitement. Un nouveau uploader, c'est une ligne d'héritage.
Tout ce qui est sensible vit dans `ir.config_parameter` : le bucket S3, la région, la clé d'accès, le secret, l'URL et la clé API Django. Pas de substitution au déploiement, pas de secret commité, pas de surprise quand un environnement manque une clé.
Les documents uploadés vont droit à S3 avec une clé déterministe. Odoo ne les garde jamais après la fin de l'upload. Les utilisateurs Django authentifiés reçoivent une URL S3 présignée de 60 secondes quand ils demandent un téléchargement — assez long pour cliquer, assez court pour qu'une URL partagée soit déjà morte.
Trois modèles Odoo avaient besoin du même comportement d'upload S3. Nous avons écrit un mixin abstrait : l'héritier déclare ses fichiers, le mixin gère la génération de clé, l'upload S3 et un POST vers l'endpoint Django `/api/index/` avec `X-API-Key`. Un nouveau uploader, c'est une ligne d'héritage.
Odoo écrit ; Django indexe. Après chaque upload S3 réussi, Odoo POSTe les métadonnées (student_reference, scholar_year, s3_key, filename) vers l'endpoint Django `/api/index/`, verrouillé par un header `X-API-Key`. Django upsert une ligne `DocumentIndex`. Le côté Django n'écrit jamais vers S3 ni vers les tables Odoo.
Les téléchargements passent par Django, qui génère une URL S3 présignée de 60 secondes à la demande. Assez long pour cliquer, assez court pour qu'une URL partagée soit morte avant de pouvoir être détournée. Pas de liens publics longue durée.
Les clés des objets encodent leur contexte : `{status_no}/{scholar_year}/{slug}.{ext}`. Deux opérations sortent gratuites : le listing par cohorte est un simple scan de préfixe S3, et migrer des documents entre environnements devient un renommage de clé plutôt qu'une jointure de métadonnées.