27.4 Perspectives d'évolution

🆕 Section prospective — non demandé aujourd'hui

Ce qui peut suivre à moyen terme. Rien ici n'est planifié : la liste existe pour cadrer la trajectoire et pour que les décisions d'architecture prises maintenant ne ferment pas ces portes inutilement.

Trajectoire identifiée

Piste	Contenu	Déclencheur / prérequis
Reporting avancé	Rapports planifiés et diffusés (standard TestRail), courbes de tendance multi-campagnes, comparatif inter-versions, filtres par entité et par testeur	A1 livré + canal de diffusion (Q16)
Tableaux de bord personnalisables	Widgets réagençables par utilisateur (PractiTest, qTest, gadgets Jira de Zephyr)	A1 livré ; ne se justifie qu'avec plusieurs profils de lecteurs
Versionnage des cas de test	Historique des modifications d'un flux avec différentiel — proposé nativement par TestRail et Zephyr Scale. Répond en partie à « qu'est-ce qui a changé depuis la campagne précédente ? »	Surtout utile une fois A6 en place
Champs personnalisés & étiquettes	Champs sur mesure au niveau cas / campagne / exécution, tags libres	Se justifie au 2ᵉ client — un champ sur mesure pour un seul client est une colonne, pas une fonctionnalité
Modèles de cas de test	Gabarits pré-remplis par type de flux	Après A9 — les étapes partagées couvrent déjà l'essentiel du besoin
Intégration Jira réelle	Créer le ticket depuis l'anomalie et synchroniser son statut, au lieu du champ texte jiraLink (§18)	Q10. Le round-trip Excel d'A7 couvre l'essentiel du besoin entre-temps
Notifications métier	Anomalie assignée, campagne clôturée, rapport hebdomadaire — même prérequis technique que l'e-mail du dashboard A1	Q15 + Q16
Baselines / variantes de référentiel	Branches du référentiel pour maintenir plusieurs versions ERP en parallèle (modèle TestRail)	À ne construire que si le besoin multi-versions simultanées est confirmé (Q11) — sinon complexité pure
Permissions par projet et groupes d'utilisateurs	Rôles configurables par projet, groupes, permissions par type d'objet (TestRail, Zephyr Scale)	Dépend de Q11 (multi-projet) et du nombre réel d'utilisateurs
API REST publique & webhooks	Exposer les fonctions Convex derrière une API stable, versionnée, authentifiée par clé	Pertinent seulement si un système tiers doit lire ou écrire dans l'outil
API d'ingestion de résultats	Permettre à des tests automatisés de pousser leurs résultats (les trois outils étudiés en ont une)	Pertinent seulement si des tests automatisés existent côté client
IA au-delà de la génération	Résumé automatique d'une exécution en échec en description d'anomalie ; détection des flux à risque ou instables ; détection de doublons de cas (les trois éditeurs y vont ; HaloAI et SmartFox le font déjà)	A5 validé en POC d'abord
SSO / SAML / SCIM	Authentification déléguée à l'annuaire du client, provisionnement automatique des comptes	Demandé dès qu'un grand compte impose sa politique d'identité — voir Q34
Mentions, abonnements, fil d'activité enrichi	@mention, watch sur un flux ou une anomalie	Même prérequis que les notifications (Q15)

Ce qui restera hors périmètre

Écarté explicitement, pour que l'écart soit assumé et documenté plutôt que subi :

Écarté	Raison
BDD / Gherkin / Cucumber	La recette visée est fonctionnelle et manuelle, conduite par des consultants métier — pas par des développeurs
Plugins CI (Jenkins, GitHub Actions, Azure DevOps)	Même raison
Génération de code d'automatisation par IA	Même raison
Sessions de test exploratoire	Pratique agile, sans usage identifié dans une recette ERP contractualisée par plan de test
Assistant conversationnel sur le référentiel	Effet de démonstration ; l'écran de recherche et les filtres enregistrés (A11) répondent au besoin réel
Suites de tests multiples par projet	Le modèle suppose un projet actif (Q11) ; la hiérarchie module → fonctionnalité → scénario suffit

Limite structurelle à garder en tête

La technologie retenue est conçue pour une application interactive temps réel, pas pour de l'analyse de données. Toute piste de cette page qui relève de la business intelligence — tableaux croisés libres, entrepôt de données, corrélations entre plusieurs projets — ne se traitera pas dans l'application elle-même, mais par une extraction périodique vers un outil dédié.

Ce n'est pas un défaut à corriger : c'est une limite à connaître avant de promettre.

Convex est OLTP, pas OLAP : pas de SQL ad hoc, pas d'agrégation sur des millions de lignes, pas de jointure multi-tables complexe en une requête. Les deux voies de sortie sont convex export (sauvegarde zip, analyse ponctuelle) et le connecteur Fivetran (réplication continue vers un entrepôt). Voir Exigences non-fonctionnelles § 14.1.