Analyse par thématique
Qualité et maintenabilité
En bref :
- Les pratiques d’ingénierie sont réelles : TypeScript, lint, tests, CI,
CODEOWNERS, pull requests.- Elles couvrent les usages collaboratifs, pas les risques d’un portail public (HTML brut, cache, non-divulgation).
- La dette vient de la personnalisation : sans points d’extension maintenus, adapter Projects revient à forker.
Pratiques observées
| Domaine | Frontend | Backend | Lecture d’audit |
|---|---|---|---|
| Formatage et analyse | Prettier, Stylelint, ESLint, typecheck Nuxt | Ruff | Base homogène |
| Tests | Vitest, Playwright | Pytest, pytest-django | Socle significatif |
| CI | Format, lint, typecheck, tests | Format, migrations, traductions, tests | Blocage des merges à confirmer |
| Propriété | CODEOWNERS (5 comptes) | CODEOWNERS (4 comptes) | Activité actuelle à confirmer |
| Dépendances et conteneurs | Lockfile, build Docker | pyproject.toml, scan d’image | Politique d’upgrade et seuils à obtenir |
Le snapshot compte environ 298 fichiers de tests pour 1 228 fichiers JS/TS/Vue, et 213 pour 651 fichiers Python. Ce ratio n’est pas un taux de couverture.
Preuves manquantes
- obligation de revue (protection de branche), au-delà du fichier
CODEOWNERS; - taux de couverture et tests des parcours anonymes, SEO, RGAA et sécurité ;
- blocage d’une release par les findings de sécurité ;
- release et rollback sans auteur historique unique (équipe) ;
- matrice de compatibilité frontend / backend / shared / Apollo, versionnés séparément.
Dette de personnalisation
| Besoin public | Complexité importée | Dette induite |
|---|---|---|
| Consultation anonyme | Authentification, rôles, workflows d’édition | Surface d’attaque, régressions |
| Pages stables | SSR par requête, no-store global | Coût serveur, TTFB variable |
| Design Paris-Saclay | Navigation d’un outil collaboratif | Surcharges CSS, conflits d’upgrade |
| Fiches de recherche | Coédition, temps réel, chatbot | Bundle et exploitation sans valeur publique |
La personnalisation directe n’est rationnelle que si LPI démontre que les fonctions inutiles sortent du build public, que le thème repose sur des points d’extension maintenus et qu’aucun fork permanent n’est nécessaire.
Coût de possession
Les coûts initiaux, annuels et à 3 et 5 ans sont chiffrés sur une seule page : scénarios et coûts comparés. L’option LPI adaptée n’y a pas de coût annuel (postes manquants). Le POC de pertinence et ses jalons de décision sont dans la feuille de route.