Ce que ces cartes ne feront jamais

L'URL iCal, l'identité et le PDF d'emploi du temps

L'intégration expose ces trois données par des services à réponse, et non par des entités. Ce n'est pas un oubli : c'est la raison d'être de ce choix.

L'URL iCal donne accès à l'emploi du temps complet d'un élève sans aucun identifiant. Quiconque l'obtient l'a pour de bon. Elle se traite comme un mot de passe.

Une carte est une surface partageable par construction : une capture d'écran, un partage d'écran en visioconférence, un tableau de bord ouvert sur une tablette de cuisine, une photo envoyée pour demander de l'aide. Aucune de ces trois données n'y a sa place.

Le type qui décrit ce qu'une carte peut faire n'autorise que deux appels de service — tenter d'en passer un autre ne compile pas :

• pronote_ng.refresh, qui ne place aucune requête PRONOTE : il relève une priorité auprès de l'ordonnanceur (détail plus bas) ;
• todo.update_item, qui coche un devoir sur une entité todo de Home Assistant — sans rapport avec le limiteur ni avec les données ci-dessus.

Les six services à réponse qui exposent ces trois données restent donc hors d'atteinte par le type : une carte ne peut ni les appeler directement, ni s'en approcher en passant un couple domaine/service arbitraire à la place des deux ci-dessus.

À côté de cette garantie de type, un test de garde relève tous les sites d'appel de service présents dans le code et exige que chacun tire son couple domaine/service de la liste ci-dessus ; il vérifie en outre que le point d'entrée non restreint de Home Assistant ne s'atteint que depuis l'unique pont du socle. C'est une vérification de texte, complémentaire à celle du type et non un substitut : elle porte sur les sites d'appel, pas sur toute mention possible d'un nom de service ailleurs dans un fichier. Un second test échoue si le nom de l'un des six services réapparaît dans le code ou la documentation publiée, pages de la racine comprises.

Cette page est la réponse aux demandes de carte « emploi du temps PDF » ou « fiche élève complète ». La réponse est non, et elle ne dépend pas de qui demande.

Le journaliseur pronotepy

Ne l'activez jamais. Au niveau DEBUG, il écrit l'hexadécimal de chaque requête, identifiants compris. Pour déboguer, activez uniquement :

logger:
  logs:
    custom_components.pronote_ng: debug

Le déclenchement de collectes

Aucune carte ne provoque de collecte en s'affichant. Le serveur PRONOTE sanctionne l'adresse IP, et tout le budget de requêtes est géré par un limiteur côté intégration.

La carte « limiteur » propose un bouton qui appelle pronote_ng.refresh. Ce service ne place aucun appel : il relève une priorité auprès de l'ordonnanceur. Un boost est plafonné à un par palier et par intervalle, et le bouton se grise en conséquence — cliquer plus n'obtient pas plus.

Le choix de la période (trimestre, semestre)

Aucune carte ne propose de sélecteur de période : les notes et la vie scolaire affichées sont toujours celles de la période en cours. Il n'y a aucun moyen d'afficher, depuis une carte, une période close — le trimestre 1 une fois le trimestre 2 commencé, par exemple.

Ce n'est pas un oubli : c'est un trou structurel. Pour chaque période close qu'elle suit, l'intégration crée un jeu d'entités suffixées par un index. Mais toutes ces entités, sur un même appareil, partagent le même translation_key — c'est exactement la clé que les cartes utilisent pour retrouver une entité. La résolution ne peut donc pas distinguer un trimestre 1 d'un trimestre 2 : elle rendrait l'une des deux entités au hasard de l'ordre dans lequel le registre de Home Assistant les liste.

Il reste une échappatoire, et il faut la décrire honnêtement : l'option entities d'une carte permet de désigner un identifiant d'entité précis pour une clé donnée, en contournant entièrement la résolution. Écrite à la main dans le YAML de la carte, elle épingle donc une période close :

type: custom:pronote-ng-notes
device_id: <appareil de l'enfant>
entities:
  sensor:grades: sensor.<enfant>_notes_2

Ce n'est pas recommandé, et aucune interface ne le propose, pour une raison qui vaut d'être dite plutôt que cachée : cet identifiant dérive du nom affiché de l'enfant dans Home Assistant (voir Installation). Renommer l'appareil, ou installer la carte sur une autre instance, casse la configuration en silence — la carte affichera « entité introuvable ». C'est le seul endroit du projet où un identifiant d'entité est écrit en dur, et c'est vous qui en portez la conséquence.

La surcharge subit la même vérification de domaine que le chemin normal : une clé sensor:... ne peut se résoudre qu'à un sensor.. Un identifiant d'un autre domaine est ignoré, pas accepté sans un mot.

Si vous n'avez pas besoin de l'épingler dans un tableau de bord, consultez la période close directement dans PRONOTE ou dans l'historique de l'intégration.

Traduire ce que l'établissement a écrit

Plusieurs textes viennent du serveur, tels que l'établissement les a saisis : les libellés de maîtrise d'une évaluation (« Très bonne maîtrise »), les motifs d'absence, la durée d'une absence (« 2h00 »), les appréciations du bulletin, les énoncés de devoirs.

Aucun n'est traduit, ni reformulé, ni normalisé. Traduire une échelle de maîtrise inventerait une échelle qui n'est pas celle de l'établissement ; recomposer une durée écrite à la main lui ferait dire autre chose. Les quatre catalogues de langue ne portent que les mots de l'interface.

Et aucune contradiction apparente n'est réconciliée. Le cas relevé sur une installation réelle :

justified: true
hours:     "2h00"
reasons:   ["MALADIE SANS CERTIFICAT"]

La carte affiche les trois côte à côte : 2h00 · MALADIE SANS CERTIFICAT, avec la pastille « justifiée ». Ça se lit comme une incohérence et ça n'en est pas une. Le motif est ce que la famille a fourni, le drapeau est ce que l'établissement a accepté : la vie scolaire a justifié l'absence malgré l'absence de certificat. Les deux sont vrais et ils ne parlent pas de la même chose. Masquer l'un au nom de l'autre effacerait l'information la plus intéressante des deux.

Corollaire pour une automatisation : la justification se lit dans justified, jamais en cherchant un mot dans reasons. Une condition qui cherchait « sans certificat » conclurait ici l'exact contraire de la vérité.

Injecter le HTML du serveur

PRONOTE écrit les énoncés de devoirs en HTML. Aucune carte ne les insère dans la page comme du balisage — ni pour l'afficher, ni pour s'en débarrasser. Le texte lisible est obtenu par un retrait purement textuel, ou mieux, lu depuis la variante en texte simple que l'intégration publie.