Deux métiers différents
L’OCPP Compliance Testing Tool de l’Open Charge Alliance sert un objectif précis : certifier qu’un produit respecte la spécification OCPP avant sa mise sur le marché. Il est complet, officiel, et conçu pour produire un résultat de conformité qui veut dire quelque chose pour un service achats.
Il n’est pas conçu pour un flux de développement. Ce n’est pas une critique — c’est simplement un autre outil pour un autre métier.
Comprendre la différence évite beaucoup de frustration.
Ce que l’OCTT fait bien
L’OCTT déroule une suite de tests complète et normalisée contre votre implémentation. Les tests couvrent de façon structurée les fonctions obligatoires et optionnelles de la spécification. Quand vous passez, vous disposez d’une preuve documentée de conformité qui pèse auprès des grands comptes et des énergéticiens.
Le processus est aussi un garde-fou utile. Devoir certifier formellement son produit interdit de livrer avec une conformité protocolaire « à peu près ». La barre est clairement définie.
Là où l’OCTT ne colle pas au développement
Le processus de certification s’articule autour d’un modèle de jalon : vous construisez la chose, vous testez la chose, vous certifiez la chose. Le développement est itératif. Vous testez après chaque changement significatif, pas une seule fois à la fin.
L’OCTT demande aussi de la coordination — planifier des sessions de test, obtenir l’accès à l’outillage, soumettre les résultats. Cette surcharge est acceptable pour un jalon de certification. Elle est intenable comme boucle de développement quotidienne.
Le vide au milieu
Ce dont un développeur a réellement besoin, c’est de quelque chose qui :
- démarre immédiatement, sans planification
- donne un retour rapide sur des échanges de messages précis
- fonctionne en environnement de CI
- fournit assez de détail pour déboguer vite un échec
C’est le vide que TestPilot est fait pour combler. Il ne remplace pas l’OCTT — s’il vous faut la certification OCA, vous devrez toujours passer par là. Mais il prend en charge les 95 % de vos tests qui ont lieu avant que vous soyez prêt pour la certification formelle.
Un flux de travail typique
En pratique, le déroulé ressemble à ceci :
- Développement : faites tourner TestPilot dans votre environnement local. Testez chaque flux de messages au fur et à mesure que vous l’implémentez. Utilisez-le en CI pour attraper les régressions.
- Pré-certification : faites tourner TestPilot sur l’implémentation complète, comme contrôle avant décollage. Corrigez tout ce qui échoue.
- Certification : soumettez à l’OCTT de l’OCA. À ce stade, vous devriez déjà savoir que les flux principaux passent.
- Après la certification : continuez à utiliser TestPilot pour développer la version suivante. Une certification est un instantané ; le développement, lui, continue.
Notes pratiques sur l’intégration OCTT
Si vous préparez une certification OCTT, quelques points méritent d’être connus :
La suite de tests est organisée par profil (Core, Remote Trigger, Smart Charging, etc.). Sachez pour quels profils vous revendiquez la conformité avant d’entamer le processus.
L’OCTT teste des cas limites que vos exécutions habituelles n’atteignent peut-être pas — réponses d’erreur, transitions d’état inattendues, champs optionnels absents. Confrontez votre implémentation au plus grand nombre possible de ces scénarios pendant le développement.
Conservez vos journaux de test. Quand quelque chose échoue en certification formelle, disposer de journaux détaillés issus de vos tests de développement rend l’analyse des causes bien plus rapide.