Carnet RRUPN : outiller le suivi d’activité de référent numérique d’établissement

Retour d’expérience : une application libre, locale et sans serveur de données, développée en établissement et partagée sur la Forge des communs numériques éducatifs.

Un besoin de terrain rarement outillé

La mission de référent aux ressources et usages pédagogiques numériques recouvre, dans un collège ou un lycée, un ensemble de tâches très hétérogènes : maintenance de premier niveau sur les postes et leurs périphériques, gestion des comptes et des accès, accompagnement des collègues dans leurs usages, relation avec la collectivité de rattachement et avec l’assistance académique, suivi de l’inventaire.

Cette activité se déploie par fragments de quinze minutes, entre deux séquences, rarement à un poste de travail. Elle laisse peu de traces écrites. En fin d’année, lorsque le chef d’établissement demande un compte rendu de la mission — préalable habituel à la reconduction de l’indemnité —, le référent reconstitue de mémoire une année entière d’interventions. L’exercice est approximatif et, surtout, il sous-estime systématiquement le travail réalisé.

Les outils existants répondent mal à ce cas d’usage. Les solutions de billetterie de type GLPI supposent que les demandeurs déposent eux-mêmes leurs tickets, ce qui n’est ni réaliste ni souhaitable à l’échelle d’un établissement du second degré : la demande arrive dans un couloir, oralement. Les outils de suivi du temps issus du monde de la facturation imposent des notions de client et de projet sans objet ici, et ignorent la dimension centrale du métier : ce qui a été transmis à un tiers et n’a pas abouti.

C’est pour combler cet écart qu’a été développée l’application Carnet RRUPN.

Principe : une saisie en dix secondes, sans réseau

L’application est une application web progressive (PWA) entièrement locale. Elle s’installe sur le téléphone depuis une adresse web, puis fonctionne sans connexion. Il n’y a ni serveur, ni compte utilisateur, ni transmission de données.

Ce choix n’est pas seulement technique : il conditionne l’usage. Une intervention se saisit debout, dans une salle où le réseau est précisément en panne. L’écran d’accueil présente donc une grille de catégories en gros boutons — un appui court ouvre la saisie de durée avec des raccourcis de 5 minutes à 2 heures, un appui long déclenche un chronomètre qui survit à la fermeture de l’application.

Les catégories, comme les destinataires des demandes transmises, sont entièrement paramétrables : chaque établissement peut les ajuster à son organisation sans modifier le code.

Trois apports structurants

Distinguer le réalisé du prévu

Chaque intervention porte un état : demande, en cours ou terminé. Une sollicitation reçue mais différée est enregistrée sans durée et rejoint une liste de travail sur l’écran d’accueil, d’où le chronomètre peut être lancé et rattaché à cette tâche — le temps mesuré s’y ajoute au lieu de créer un doublon, ce qui autorise un travail fractionné sur plusieurs jours.

Le bilan annuel ne comptabilise que le travail achevé, mais mentionne les demandes restées en attente. Cette information a sa valeur propre : elle documente la charge non absorbée.

Suivre les tickets déposés

Une part significative de l’activité consiste à constater une panne puis à la transmettre : à la direction des systèmes d’information de la collectivité, à l’assistance académique, au prestataire de l’ENT. Ce travail est invisible dans un simple décompte d’heures.

L’application suit donc ces remontées selon quatre statuts — en attente, en cours, résolue, sans suite — le dernier couvrant les demandes refusées, abandonnées ou restées sans réponse. Chaque remontée accepte des points de suivi datés (relances, réponses reçues, pièces commandées).

Le bilan en tire un délai médian de résolution, calculé sur les seules demandes effectivement résolues, et une ventilation par destinataire. Cette ventilation constitue un élément objectif de dialogue, tant avec la collectivité qu’en interne lors de l’élaboration des demandes de moyens.

Constituer l’inventaire au fil de l’eau

Le numéro d’inventaire porté par l’appareil dépanné est un champ facultatif. Dès qu’il est renseigné, l’appareil entre au parc et s’y rattache au lieu de l’intervention. Une seconde saisie du même numéro repropose la description et le dernier lieu connus, en signalant le nombre d’interventions déjà enregistrées — indication utile pour identifier les matériels à renouveler.

Le numéro peut être saisi au clavier, lu par reconnaissance de caractères au moyen de la fonction native d’iOS, ou scanné par la caméra. Un inventaire préexistant peut être importé depuis un fichier CSV.

Protection des données

L’application a été conçue selon une logique de minimisation.

Les données sont enregistrées dans le stockage local du navigateur de l’appareil et ne sont transmises à aucun serveur — l’application n’effectue aucun appel au réseau après son chargement initial.

Surtout, aucune identité de collègue n’est enregistrée : seul le lieu de l’intervention (salle, service) est saisi. Ce choix est délibéré. Le document produit en fin d’année étant destiné à la direction de l’établissement, il n’était pas souhaitable d’y adosser un suivi nominatif des personnels sollicitant le référent. Le champ n’existe pas, ce qui écarte la question à la source.

Le corollaire à connaître est que la sauvegarde relève de l’utilisateur : l’application propose des exports (sauvegarde complète ré-importable, exports CSV), qu’il convient d’effectuer périodiquement.

Un commun numérique éducatif

Le code est publié sur la Forge des communs numériques éducatifs sous licence GNU AGPL v3, avec l’ensemble de sa documentation d’installation.

Techniquement, il s’agit d’un fichier HTML et de ses scripts associés, sans autre logiciel que le navigateur, sans ressource externe, sans police téléchargée. Les graphiques du bilan sont produits en SVG. L’application s’héberge sur les pages statiques de la Forge en quelques minutes, avec le modèle de projet « Plain HTML ». Seule la lecture de codes-barres s’appuie sur une bibliothèque tierce sous licence Apache 2.0, chargée à la demande et non au démarrage.

Cette sobriété technique est un choix de pérennité : une application sans dépendance ne se périme pas au rythme des mises à jour d’un écosystème, et reste intelligible par un collègue qui souhaiterait la reprendre.

Tout établissement peut donc l’installer, l’adapter à ses catégories et à ses interlocuteurs, ou en dériver une version propre.

Sur la méthode de développement

L’application a été développée avec l’assistance d’un modèle de langage (Claude, Anthropic). La conception — analyse du besoin, choix fonctionnels, arbitrages d’ergonomie, décision de ne pas enregistrer d’identités — relève de l’auteur, de même que la recette : chaque version a été éprouvée en conditions réelles d’établissement, et plusieurs défauts n’ont été identifiés que par cet usage. L’écriture du code a donc été largement assistée.

Ce mode de production mérite d’être signalé pour lui-même : il rend accessible à un enseignant sans formation de développeur la réalisation d’un outil métier documenté et maintenable, tout en déplaçant l’exigence vers la spécification, le test et la relecture — qui restent, elles, entièrement humaines.

Limites et perspectives

L’honnêteté impose d’en énoncer les contraintes.

L’application est mono-appareil : les données résident sur le téléphone, et la synchronisation entre plusieurs terminaux passe par un export et un import manuels. La sauvegarde n’est pas automatique. La bibliothèque de lecture de codes-barres n’est plus activement maintenue par son auteur depuis 2023 ; elle demeure fonctionnelle, et un mode de saisie de repli est prévu si elle venait à cesser de l’être.

Une mutualisation à l’échelle d’un bassin ou d’un département — qui permettrait d’objectiver la charge de la mission au-delà d’un établissement — supposerait une architecture différente, avec les questions d’hébergement et de traitement de données que cela emporte. Ce n’est pas l’objet de cette version, volontairement modeste et centrée sur l’usage individuel.

Pour aller plus loin

Le projet, sa documentation- et ses conditions de réutilisation sont accessibles à l’adresse suivante :

https://forge.apps.education.fr/clement.lefevre/carnet-rrupn

L’application quant à elle est accessible ici :
https://carnet-rrupn-7982bc.forge.apps.education.fr/

Ou via le lien court : https://edurl.fr/rrupn

Les retours d’usage sont bienvenus, en particulier sur les catégories d’intervention retenues : c’est le paramètre le plus structurant de l’outil, puisqu’il détermine ce que le bilan annuel donnera à voir de la mission.

Clément Lefèvre, professeur de S.V.T. et référent pour les ressources et usages pédagogiques numériques au collège Fernand Léger, Le Petit-Quevilly (76). Application développée à titre personnel et partagée sous licence libre.

Publié le
par Sophie Bocquet-Tourneur

Intelligence artificielle

L’IA n’a pas été utilisée pour générer tout ou partie de cet article.

Partager

Imprimer cette page (impression du contenu de la page)