SACoche : Évaluer par compétences et estimer la maîtrise du socle commun

En 2013, l’académie de Bordeaux a demandé que SACoche soit installé sur un serveur qu’elle maintient pour ses établissements, avec une authentification "Shibboleth".
Bordeaux est la seule académie à avoir imposé ce mode d’authentification, qui a nécessité un développement spécifique.
Cela contraint SACoche à appeler un service, nommé Sarapis, pour la connexion académique, alors que dans toutes les autres académies c’est un connecteur classique qui est utilisé.
Et c’est probablement aussi le cas pour toutes les autres applications académiques autorisées.

• Pourquoi cette contrainte est-elle imposée à SACoche et pas aux autres services ?
  Personne n’explique cette discrimination.

De plus, depuis cette date, les établissements de l’académie de Bordeaux ne peuvent pas utiliser SACoche directement.
Ils doivent en formuler la demande en envoyant un courriel aux chargés de mission de l’ENT académique, à une adresse qui, après vérification, ne répond pas !

• Pourquoi cette contrainte est-elle imposée à SACoche et pas aux autres services ?
  Personne n’explique non plus cette discrimination.

L’application SACoche est mise à jour chaque mois par nos soins ; elle est compatible avec les toutes dernières versions PHP et MySQL.
Le serveur, en revanche, appartient et est géré par l’académie de Bordeaux ; il n’a lui jamais été mis à jour.
Il est resté dans une configuration obsolète, sous PHP 5.3, qui n’est plus supporté depuis août 2014 !
Les risques encourus sont réels : absence de correctifs de sécurité, vulnérabilités critiques exploitables, compromission du serveur, incompatibilité et obsolescence logicielle.

• Il s’agit d’un manquement grave des services informatiques de l’académie.

Une telle rétrocompatibilité nous coûte du temps et des complications de développement.
Ainsi plusieurs mises à jour de SACoche ont planté l’application à cause d’un élément de langage incompatible avec PHP 5.3.
Thomas Crespin a alerté plusieurs fois à ce sujet, et demandé à migrer sous un serveur PHP plus récent.
Dernières évocations par courriel en date du 19 mars 2026 et du 18 mai 2026.

• Aucune suite n’a été donnée, aucune réponse n’a été reçue.

Enfin, le service Sarapis que SACoche est obligé d’utiliser pour authentifier les utilisateurs dysfonctionne régulièrement.
Ce qui entraîne des perturbations et nous impose un travail supplémentaire d’explication aux utilisateurs bloqués.
Ainsi à la rentrée de septembre 2025 il a fallu attendre 10 jours avant qu’élèves et parents ne puissent se connecter.
Et aucune excuse n’est jamais présentée par les services informatiques de l’académie.

Comme l’année précédente, élèves et parents ont rencontré des dysfonctionnements pour se connecter à SACoche.
À cause d’annuaires non synchronisés et du service Sarapis que SACoche est contraint d’utiliser.

Thomas Crespin a alerté le SRASI à ce sujet le 1^er septembre, le 2 septembre, le 3 septembre... avant qu’un agent du SRASI ne réponde nous te tiendrons au courant quand les export seront reparti.
Ensuite, plus aucune nouvelle.

Après une semaine de patience passée à gérer la situation et les incompréhensions des utilisateurs, Thomas Crespin a relancé le 10 septembre, et le 11 septembre ce même agent lui a répondu les exports Complet 2D pour les ENT ont été relancé.
Mais les dysfonctionnements demeuraient.

Thomas Crespin a donc encore relancé les services informatiques de l’académie le 14 septembre.
Puis l’impensable s’est produit le lendemain.

Le 15 septembre au matin, sans aucun préavis, le serveur SACoche de l’académie de Bordeaux a été mis hors ligne.
Sur décision du DRAASI, au regard de la sensibilité des données, du volume de données traité, de l’obsolescence des logiciels et de l’OS des hébergements, et de la faible audience.

Thomas Crespin a immédiatement réagi pour faire part de son incompréhension :

• coupure brutale sans préavis à cause d’une situation dont l’académie est la seule responsable
• utilisateurs déconsidérés, victimes, dépossédés de leurs données et de leur outil de travail, empêchés de fonctionner, initiatives pédagogiques annihilées
• possibilité de laisser le service ouvert encore quelques jours en attendant de trouver une solution et de récupérer ses données de travail (vu les défaillances et l’inaction de l’académie depuis plus de 10 ans)
• demande d’une reconsidération de la situation et une réouverture immédiate du serveur
• mise à disposition et proposition d’aide pour adapter le mode d’authentification et assister la migration sur un autre serveur

Le DRAASI lui a répondu rapidement, mais en ignorant ses arguments, invoquant la nécessité de :

• mitiger immédiatement un risque de fuite de donnés, de vol d’identité et au final de mise à l’arrêt de l’académie
• mettre en sécurité le temps de réaliser les actions nécessaires comme la mise à jour des serveurs vers les dernières versions
• réaliser un audit du code pour avoir l’assurance d’être protégé contre des failles

Il conclut : nos activités actuelles vont prioritairement à celles pour lesquelles nous devons rendre compte à l’ANSSI, ayez néanmoins l’assurance que les actions évoquées seront programmées aussi rapidement que possible.

Confronté à la confiscation du service et l’injustice de la situation, Thomas Crespin a utilisé les formulaires "signaler un problème informatique" et "contacter les médiateurs" à disposition (mais bien cachés) sur le portail académique.
Après soumission, on obtient l’affichage nos équipes mettent tout en œuvre afin de vous répondre au plus vite et on reçoit une réponse automatique confirmant que le message a été pris en compte et enregistré.

• La réalité est bien différente : aucune réponse n’a suivi !

Thomas Crespin a aussi utilisé le formulaire d’assistance académique Amérana, à chaque sollicitation d’utilisateurs nous contactant à ce sujet, ou de besoin d’accéder à l’outil ou ses données pour exercer son métier.
Voici un exemple d’argumentaire envoyé :

Je comprends parfaitement qu’une faille ou une situation présentant un risque de sécurité puisse conduire à interrompre temporairement un service. En revanche, la manière dont cette interruption a été effectuée pose un problème important de continuité de service pour les établissements qui utilisent SACoche.
Cette situation est d’autant plus difficile à comprendre que j’ai signalé à plusieurs reprises l’obsolescence ou les problèmes de sécurité liés à ce serveur. Ces alertes étaient donc connues bien avant l’arrêt du serveur, et pour autant rien n’a été fait.
Une mise à niveau du serveur, une migration vers une infrastructure plus récente, ou toute autre solution permettant de maintenir le service, aurait pu et dû être envisagée en amont.
Je voudrais donc obtenir des réponses précises sur les points suivants :
- 1. Quelle était précisément la vulnérabilité ou le risque de sécurité ayant conduit à l’arrêt du serveur ?
- 2. Depuis quand cette situation était-elle identifiée par les services de l’académie ?
- 3. Pour quelles raisons aucune mise à niveau ou migration n’a-t-elle été mise en œuvre avant l’interruption ?
- 4. Pourquoi les établissements utilisateurs n’ont-ils pas été informés préalablement de cette coupure ?
- 5. Pourquoi le référent académique en charge de l’application n’a pas été informé préalablement de cette coupure ?
- 6. Quelles mesures sont actuellement envisagées pour permettre aux établissements de retrouver l’accès à SACoche ?
- 7. Quelle solution temporaire de remise en service sécurisée, dans l’attente d’une migration définitive, peut être mise en place ?
- 8. Combien de temps précisément les utilisateurs vont-ils encore devoir subir cette situation ?
Il ne s’agit évidemment pas de contester la nécessité de protéger les systèmes d’information de l’académie. Il s’agit de comprendre pourquoi un problème connu depuis plusieurs années aboutit aujourd’hui à une interruption brutale d’un service utilisé par de nombreux établissements, sans solution de continuité préalablement prévue, d’en identifier les responsabilités, de faire comprendre qu’une levée rapide du blocage est attendue.

Mais les tickets ont été évacués sans résoudre la situation ni répondre aux questions, avec comme seuls retours lapidaires :

• c’est un probleme de serveur
• ca ne sert à rien de faire d’autre tickets
• demande en double
• le service est mis à l’arret le temps de sa mise à jour

Le problème n’étant pas réglé, les tickets ont été réouverts.
Le service d’assistance les a alors fermés sans même y répondre.
Il a même ensuite coupé les notifications de fermeture.

À force d’insister, le 21 septembre, le DRAASI a fini par envoyer une réponse un peu plus fournie à Thomas Crespin :

• Votre mécontentement a clairement été noté et pris en bonne note, il n’est pas utile de submerger de demandes Amerana pour vous en épancher plus grandement, à moins de vouloir également pénaliser encore plus vos autres collègues enseignants du fait du temps pris par les techniciens pour traiter vos demandes multiples répétées et identiques.
• Le service SACoche sera prochainement rétabli, mais il n’est pas vital pour l’académie aussi vous devez comprendre que nous devons arbitrer entre vos priorités, celles de vos autres collègues, et celles que le ministère nous enjoint de respecter dans des délais contraints.

Ce message, en plus d’être culpabilisant, ne répondait à aucune des questions.
Dans la foulée, le compte de Thomas Crespin a été banni de la plateforme d’assistance.

Le 23 septembre le DRAASI envoie un courriel intitulé Réouverture SACoche.
Il s’adresse à Thomas Crespin, avec en copie Olivier Jaccomard et le DRASI.
Il annonce qu’un environnement dit "de qualification" a été mis en place en urgence, ayant pour objectif de permettre la validation du comportement de la dernière version de SACoche avant son déploiement sur un autre environnement dit "de production", qui remplacera à terme l’environnement actuellement à l’arrêt car largement obsolète.

Il évoque néanmoins deux points à retravailler avant la réouverture :

• 1. D’une part des vulnérabilités ont été identifiées dans le code de SACoche par l’outil Checkmarx, et qu’il convient donc d’analyser le rapport pour déterminer s’il s’agit ou non d’un faux positif ; de procéder à la correction du code si positif ; de faire un retour pour récupérer la dernière mouture du code.
• 2. D’autre part les données traitées par AAF pour SACoche concernent tous les utilisateurs de toute l’Aquitaine ; le compte technique employé à cette fin dispose d’autorisation très large dépassant de très loin le simple besoin, son usurpation offensive pouvant entrainer des défaillances majeures dans le reste du SI, et qu’il convient donc de limiter la surface d’attaque et les potentielles fuite en limitant ces exports uniquement aux établissements utilisateurs de SACoche, avec la demande de lister les UAI des établissements utilisateurs de SACoche.

Les paragraphes suivants abordent ces aspects.

En préalable, rappelons que SACoche est libre, que son code source est à disposition de tous depuis toujours, et en toute transparence concernant la sécurité.
Malgré la plus grande vigilance, tout système peut comporter des failles de sécurité, et tout audit ou analyse du code par un tiers est apprécié et le bienvenu.
Cependant :

• cela aurait pu et dû être fait bien avant s’il y avait des suspicions à ce sujet ;
• cela n’imposait pas une coupure préventive (on ne coupe pas Windows aux utilisateurs alors que des failles y sont régulièrement décelées).

Ceci étant dit, Thomas Crespin s’est attelé à l’analyse du rapport Checkmarx de 241 pages.
Ce rapport recense « 130 vulnérabilités » à vérifier, dont « 4 critiques, 15 hautes, 51 moyennes et 60 basses ».

Si cela pouvait s’avérer inquiétant au premier abord, après examen approfondi, l’ensemble s’est complètement dégonflé.
Déjà, étaient dénombrées les lignes de code concernées, et non le nombre de failles.
Ainsi une même ligne "vulnérable" trouvée à 30 endroits était comptabilisée 30 fois.

Ensuite et surtout, toutes les vulnérabilités "critiques" remontées par l’outil étaient de faux-positifs, et pour les autres il s’agissait plutôt de recommandations, sans grandes conséquences éventuelles, et pas toujours pertinentes ou fondées.
Ainsi, l’analyse de ce rapport est finalement satisfaisante à double titre :

• d’une part elle montre plutôt que SACoche est bien sécurisé avec aucune faille dangereuse exploitable avérée ;
• d’autre part elle a pointé des améliorations possibles qui ont été mises en œuvre immédiatement.

Le 25 septembre, donc sous 48h, Thomas Crespin a adressé au DRAASI un compte-rendu de relecture reprenant point par point chaque élément du rapport Checkmarx.
En indiquant rester à disposition pour une issue rapide.

Le 28 septembre, un agent du SRASI contacte Thomas Crespin avec un courriel intitulé SACoche : Migration vers un nouveau serveur.
Un entretien est planifié pour le lendemain, 29 septembre.
Thomas Crespin redit essentiellement la procédure assez simple déjà décrite plusieurs jours avant, à savoir : transférer les fichiers, transférer les bases, copier la dernière version du code source par dessus.
En quelques minutes seulement, le tour de la question était fait.

Pour alléger la tâche, Thomas Crespin propose d’effectuer un nettoyage des bases d’établissement inutilisées.
L’agent du SRASI rouvre alors l’accès au serveur, pour qu’il puisse s’y connecter.
Et cet accès est resté ouvert à tous pendant plusieurs heures !
Cela prouve bien que rouvrir l’accès serait possible, il faudrait juste un peu de bonne volonté et de compréhension.

Bref, Thomas Crespin a supprimé un peu plus des deux tiers des bases, pour n’en conserver que 36.
Cela a été rapide ; il a répondu à l’agent du SRASI que c’était fait et qu’il était à sa disposition pour la suite.
Mais il n’a plus eu de nouvelles.
Il a alors relancé l’agent du SRASI une première fois, puis une seconde fois, et le 30 septembre ce dernier a répondu : je vous fait un retour dès que j’ai pu avancer.

• Cependant, plusieurs semaines plus tard, l’agent du SRASI ne l’a toujours pas recontacté !
  Le 1^er octobre, Thomas Crespin lui a exprimé son profond mal être par rapport à cette situation qui s’enlisait : aucun retour non plus.

Pour information, un administrateur système professionnel sollicité estime à environ 2 heures la durée nécessaire pour effectuer ces opérations.
Alors comment expliquer un blocage pendant des semaines supplémentaires ?
Chacun en tirera ses conclusions !

Le 23 septembre, dans son "second point à retravailler", le DRAASI demandait la liste des établissements utilisateurs.
Thomas Crespin a répondu sur le moment que nous ne la connaissions pas.
En effet, SACoche est libre et gratuit, les établissements ne sont pas nos "clients", aucun listing n’est tenu et leur activité n’est pas surveillée.
De plus, l’accès au serveur SACoche étant coupé, nous n’avions aucun moyen de consulter les inscriptions.

Le 29 septembre, un accès temporaire au serveur a permis d’y supprimer les inscriptions obsolètes.
Le 30 septembre, Thomas Crespin a transmis au DRAASI la liste des 36 inscriptions conservées.
En indiquant qu’il s’agissait des établissements encore inscrits.

Le 7 octobre, soit une semaine plus tard, le secrétariat du SRANE a envoyé un courriel à ces établissements.
En leur écrivant le développeur de SACoche nous a signalé que votre établissement utilise cet outil, et nous souhaitons en avoir la confirmation.
Et en leur demandant d’indiquer par retour de mail si vous confirmez que SACoche est utilisé dans votre établissement ; dans l’affirmative si vous nous autorisez à transmettre l’annuaire de votre établissement qui servira à alimenter l’outil.

Cette démarche appelle trois remarques :

• La liste fournie n’était pas celle des établissements utilisant SACoche cette année.
  Il s’agissait des établissements "encore inscrits sur le serveur", ce qui est différent.
  Ceux où il y a eu au moins une connexion sur les 6 derniers mois, ou parce qu’il y a de nombreux bilans officiels auxquels un ancien établissement utilisateur voudrait pouvoir accéder.
• Une fois encore, on se retrouve face à une véritable discrimination.
  Pour les autres services, l’académie ne demande ni confirmation d’usage, ni l’autorisation du chef d’établissement.
  L’académie invoque pour se justifier le webservice imposé pour la connexion, mais c’est elle qui l’a imposé, et seulement à SACoche !
• Enfin, cette démarche suppose que tous ces établissements utilisent la connexion académique.
  Or c’est loin d’être le cas.
  Un professeur des écoles qui utilise seul SACoche pour gérer les évaluations de ses élèves et remplir le LSU n’en a pas besoin.
  Ainsi, dans plusieurs situations, la demande d’autorisation formulée n’a pas de sens.

Comme indiqué précédemment, un audit réalisé avec l’outil Checkmarx a recensé de multiples vulnérabilités dans SACoche, mais comme restant "à vérifier".
Le rapport correspondant a été généré et transmis le 23 septembre.
Tout a été analysé et une réponse point par point a été faite dès le 25 septembre.
Il s’agissait de faux-positifs, ce qui montrait donc au contraire la robustesse du code.

Or le lendemain, 26 septembre, un agent du SRANE de Bordeaux, tout en soutenant SACoche en indiquant qu’il était de moins en moins utilisé à son grand regret, a communiqué sur la messagerie Tchap que :

• l’arrêt de SACoche n’est pas uniquement lié au vieillissement du serveur : des failles majeures de sécurité ont également été identifiées dans le code
• compte tenu des risques actuels [...] la décision a été prise de suspendre le service le temps de le sécuriser
• les collègues du SRASI, fortement mobilisés en ce moment, ont mis en place un nouvel environnement et proposé une procédure de sécurisation en vue de la réouverture
• SACoche devra corriger les failles de sécurité qui lui ont été signalées avant toute remise en service, en attendant de migrer rapidement vers une solution plus pérenne
• il ne s’agit donc pas d’un excès de zèle, mais d’une décision réfléchie, prise par des professionnels dont les systèmes d’information sont le cœur de métier

Pour nous il s’agit d’affirmations :

• enjolivant la réalité (un serveur obsolète depuis 10 ans ne peut pas être seulement qualifié par un professionnel de "vieillissant")
• inversant les rôles et la chronologie (ce n’est pas l’audit de SACoche - seulement réalisé le 23 septembre ! - qui a conduit à la fermeture du serveur)
• trompeuses (pas de faille réelle, énormément de faux positifs, aucune exploitation n’est démontrée)
• inexactes (le nouvel environnement est invisible, nous attendons toujours que SACoche y soit installé)
• fausses (un retour a déjà été effectué concernant l’audit, il n’y a plus rien à modifier)
• dévalorisantes (d’un côté des professionnels de métier qui réfléchissent, de l’autre... un amateur stupide ?)

Hélas, cette communication fallacieuse et calomnieuse s’est poursuivie et amplifiée au moins jusqu’au 5 octobre, soit 10 jours après !
En témoignent cette réponse du SRANE aux collègues ouvrant un ticket d’assistance :

• Si SACoche a été suspendu, ce n’est pas seulement parce que le serveur vieillissait : des failles de sécurité majeures ont été identifiées dans le code source. Le service traite en plus des données très larges (tout l’AAF), sans cadre juridique à jour. Face à ces risques, mieux valait suspendre temporairement l’accès pour quelques établissements que risquer une paralysie complète comme à Toulouse.
• De son côté, l’académie a fait sa part : le SRASI a mis en place un nouvel environnement et proposé une procédure de sécurisation ainsi qu’un audit du code.
• La balle est désormais dans le camp du développeur : la remise en service dépend de la correction des failles qu’on lui a signalées, un travail qui profitera à tous les territoires utilisant SACoche.

Même minimisation concernant le serveur, même aberration temporelle de la réelle cause de la coupure, même diffamation concernant les failles de sécurité, même inversion mensongère des rôles de chacun (car le développeur de SACoche se montre extrêmement réactif, impliqué et pressant depuis le 1^er septembre, alors que c’est tout l’inverse pour "l’académie").

Chacun se fera son opinion.
De notre côté nous trouvons cela particulièrement choquant.

Il y a par ailleurs une mauvaise foi évidente dans la dramatisation : en quoi une faille dans un logiciel d’évaluation par compétences pourrait permettre la paralysie complète d’un système d’information académique ?
Une fuite de données serait problématique, mais si cela pouvait permettre d’escalader les privilèges jusqu’à remonter au système d’information utilisé pour l’authentification, alors ce serait l’aveu d’une faute professionnelle encore plus grave !

Dans les autres académies, ou sur le serveur Sésamath, SACoche reste accessible comme avant, sans aucun incident à signaler.
Pourtant, pendant ce temps là, à Bordeaux, on fait croire que c’est SACoche le problème...

Le 5 octobre, après plus d’un mois de blocage et de promesses non tenues, Thomas Crespin exprime au DRAASI son exaspération.
Quelques rappels d’écrits antérieurs de sa part :

• 15/09 : actions programmées aussi rapidement que possible
• 21/09 : le service SACoche sera prochainement rétabli
• 23/09 : environnement dit "de qualification" mis en place en urgence
• 30/09 : l’objectif reste de remettre en service l’application au plus vite

Un dictionnaire définit l’urgence comme une nécessité absolue d’agir vite face à une situation critique, qui nécessite une action immédiate pour éviter un préjudice grave, etc.
Ceci ne laisse pas supposer plusieurs semaines !

Le 6 octobre, Thomas Crespin exprime aussi son indignation face à la désinformation et au dénigrement constatés.
Il conclut néanmoins en écrivant si toutefois il demeure une volonté d’avancer de votre côté, je suis à disposition de vos techniciens toute la journée.
Cela aura permis d’obtenir une réponse.

Concernant la mise en place du nouveau serveur SACoche, le DRAASI écrit :

• l’environnement technique sous-jacent sur lequel s’appuie SACoche est en cours d’isolement
• l’environnement sur lequel le code source doit être redéployé est opérationnel, la mise à jour va être réalisée dans les jours qui viennent selon les modalités discutées avec l’agent qui vous a contacté directement

Un administrateur système professionnel sollicité estime quant à lui que :

• ces deux affirmations semblent contradictoires car si c’est "opérationnel" alors ce n’est plus "en cours d’isolement" mais "isolé"
• isoler un environnement de type LAMP ne prend que quelques minutes, sauf à avoir une très très mauvaise infrastructure pas du tout prévue pour héberger des applis web !

Le DRAASI ajoute :

• Je comprends votre empressement, mais vous devez considérer que nos priorités ne peuvent pas être uniquement concentrées sur SACoche et que votre appréciation de l’urgence ne peut s’imposer.
• Sur la forme, vos méls injonctifs et assertifs sont déplacés et je vous demande de changer immédiatement le ton de vos relances qui n’ont rien de constructives. Vous avez déjà été exclu d’Amerana du fait de vos multiples relances ressenties comme du harcèlement par nos collègues les recevant, il serait souhaitable que votre discours et votre comportement redevienne très rapidement beaucoup plus professionnel.
• Nous devrions pouvoir revenir vers vous dans le courant de la semaine afin d’entériner une date de réouverture du service probablement pour vendredi 15/10. (sic)

Thomas Crespin n’a pourtant fait que demander des réponses (non obtenues), exposer la situation, et son ressenti, certes avec franchise.
Olivier Jaccomard a répondu au DRAASI pour dire que ses propos ne sont pas en accord avec la communication qui est faîte aux établissements.

Revenons aux faits : qu’est-il advenu ensuite ?

• Concernant l’agent qui devait nous faire un retour dans les jours qui viennent : faux, déjà annoncé le 29 septembre par ce même agent, mais aucun retour de sa part depuis, et pas davantage après. Cela fait 32 jours que nous attendons !
• Concernant le fait de revenir vers nous dans le courant de la semaine, donc avant le 9 octobre : faux, personne n’est revenu vers nous, ni dans la semaine annoncée, ni même la suivante. Cela fait 25 jours que nous attendons !
• Concernant une réouverture du service au 15/10 : encore raté, aucune réouverture n’a eu lieu, ni à cette date ni les jours suivants.

Chacun estimera qui, dans cette affaire, fait preuve d’un discours et d’un comportement professionnel !

Le 19 octobre, nous mettons en ligne la première version de ce récit pour expliquer et dénoncer la situation subie.
Cela aura au moins eu le mérite de faire réagir le DRAASI.
Après 2 semaines de silence total il téléphone à Olivier Jaccomard le 21 octobre.
Mais pas pour s’excuser ni résoudre le problème : seulement pour demander que les noms des personnes impliquées (de leur côté) n’apparaissent pas dans l’article, avec la menace voilée d’un procès.
Dans un souci d’apaisement, nous décidons d’accéder à son souhait, ce même jour.
Une réactivité identique va-t-elle être enfin mise à profit du rétablissement de SACoche ?

L’épilogue de cette malheureuse affaire reste à écrire.
Les semaines passent, et le serveur SACoche de l’académie de Bordeaux est toujours coupé, depuis maintenant 46 jours.
Depuis le début, les utilisateurs de SACoche de cette académie sont traités avec condescendance et sans considération.
Ils ne peuvent pas accéder à leurs référentiels de compétences, ni évaluer leurs élèves, ni saisir de résultats, ni consulter les résultats / bilans / bulletins de l’an dernier, ni constituer de groupes de besoins ou engager de remédiation à partir de ces résultats, ni permettre aux élèves et aux familles d’y accéder, etc.

Si l’objectif est de faire abandonner SACoche aux collègues de l’académie de Bordeaux, on ne s’y prendrait pas autrement !
Le SRANE rappelle ses missions dans une communication en date du 20 octobre 2026 : il est « chargé d’accompagner le développement des usages du numérique au service de la pédagogie » et il « accompagne les établissements au quotidien, encourage les innovations et participe à leur diffusion » !
C’est pourtant exactement le contraire qui est constaté.