Le vrai risque d’une application existante, c’est ce qu’on ne voit pas
Oléo n’avait pas de problème visible : les enseignants s’en servaient chaque jour. Mais une partie du code n’existait que sur le serveur, sans copie ni historique : chaque modification se faisait sans filet.
Ce genre de fragilité ne se voit pas à l’écran. C’est pourquoi une reprise commence toujours par un état des lieux complet — le code, l’hébergement, les données — avant d’ajouter la moindre fonctionnalité.
Sur un produit existant, le risque n’est pas ce qui manque : c’est ce qu’on casse en ajoutant
Consolider l’existant sans interrompre le service
Des fondations solides, sans arrêter l’application
Le code récupéré et historisé. Tout ce qui tournait sur le serveur a été rapatrié, y compris des fichiers qui n’existaient nulle part ailleurs. Chaque modification peut désormais être relue, comparée et annulée.
Un environnement de test avant les utilisateurs. Chaque évolution est d’abord installée sur une copie de l’application, vérifiée, puis mise en ligne automatiquement.
Des données qui évoluent sans risque. Chaque changement dans la structure de la base est d’abord rejoué sur une copie des vraies données et vérifié ligne à ligne. Si quelque chose ne correspond pas, rien n’est appliqué.
Des accès vérifiés un par un. Deux audits complets du code et de la base, et des droits contrôlés compte par compte : chaque enseignant n’accède qu’à ses propres classes.
Des sauvegardes hors du serveur. Elles sont faites sans interrompre le service et rangées ailleurs : une panne de l’hébergeur n’emporterait pas les copies avec elle.
Dans votre entreprise, la question est la même : que se passerait-il demain si le serveur de votre outil tombait ?
Plus rapide, et mesuré
Les lenteurs ont été chronométrées avant d’être corrigées, puis chronométrées à nouveau. Et un défaut invisible a disparu : annoter toute une classe pouvait laisser la moitié des élèves annotés si la connexion coupait au milieu. C’est désormais tout ou rien.
Moderniser l’application à partir de l’usage réel
Les données racontaient ce que personne n’avait formulé
J’ai repris mes propres maquettes avec, en face, deux années d’usage réel. Certaines décisions tenaient, d’autres non. Et la base de données en disait plus long qu’un entretien : elle gardait la trace des contournements que les utilisateurs avaient inventés faute de mieux.
C’est la première chose que je regarde quand je reprends une application métier : ce que les gens font vraiment, pas ce qu’on croit qu’ils font.
Décision de conception
Pourquoi les enseignants effaçaient-ils leurs listes d’élèves à chaque rentrée ?
Rien ne rattachait une classe à une année : faute d’un endroit où ranger l’ancienne, on réécrivait par-dessus. La base en gardait la trace, 5 210 fiches d’élèves et 239 classes créées depuis l’origine, pour 1 024 élèves et 45 classes encore actives.
Chaque classe appartient désormais à son année. À la rentrée, celles de l’an dernier rejoignent d’elles-mêmes les archives : rien n’est déplacé ni recopié, et plus aucune manipulation risquée au pire moment de l’année.
Décision de conception
Pourquoi une même salle était-elle dessinée trois fois ?
Un enseignant avait créé « P2 », « P2 - GR1 » et « P2 - GR2 » : la même salle de 27 tables, redessinée à la main pour chacun de ses demi-groupes. L’outil ne savait pas dire « ces seize élèves-là » sans inventer une fausse classe.
Des groupes au sein d’une classe : un élève peut appartenir à plusieurs, un cours peut ne concerner qu’un groupe, et le plan de classe d’un groupe part de celui de la classe entière. Une salle se duplique aussi en un geste.
Décision de conception
Que faisait vraiment le bouton « important » ?
Presque rien : une tâche marquée importante ne passait devant que celles écrites dans le quart d’heure précédent. Personne ne l’avait signalé, parce que la fonction semblait exister.
Plutôt que de réparer un marqueur, j’ai rendu l’ordre à l’enseignant : chaque ligne se déplace à la main, et sa position dit sa priorité. Les tâches déjà marquées ont été remontées en tête, pour que rien de l’intention de départ ne se perde.
Décision de conception
Faut-il laisser l’utilisateur choisir combien de temps garder les données ?
La maquette prévoyait une option « garder indéfiniment » : c’était laisser l’utilisateur décider seul du sort de données de mineurs.
La règle est fixée par le produit : l’année en cours et la précédente, puis suppression, et l’enseignant peut seulement l’abréger. Une durée de conservation se décide par le responsable du traitement, pas au détour d’une case à cocher.
Le placement automatique, enfin réel
Les boutons « Séparer des élèves » et « Mettre ensemble » existaient, mais répondaient « Fonctionnalité disponible prochainement ». Ils fonctionnent désormais : l’outil cherche la meilleure disposition possible dans la vraie salle, et dit clairement ce qu’il n’a pas pu respecter.
RésultatSur 46 élèves et 30 tables, l’ordre alphabétique est respecté à 100 %, en moins de 50 ms.
Les vrais horaires de l’établissement
La grille allait de 8 h à 18 h par heures pleines : aucun établissement ne sonne à ces heures-là, et il fallait corriger chaque cours à la main. Elle suit désormais les vraies sonneries, les semaines A et B, et le samedi pour qui le travaille.
RésultatLes créneaux et les pauses sont enfin ceux du collège, et un cours posé prend les horaires de sa case.
Ce qu’il reste à reporter sur Pronote
Pronote ne permet pas qu’un autre logiciel y écrive : la double saisie ne peut pas disparaître, mais elle peut devenir rapide. Oléo prépare la liste exacte de ce qu’il reste à reporter, dans l’ordre où on la saisit.
RésultatLa liste à recopier le soir s’écrit toute seule dans le mémo, une tâche par classe et par jour.
L’historique d’un élève
Les annotations ne se lisaient que par catégorie : on voyait « 3 retards », jamais ce qui s’était passé jeudi. L’information existait déjà ; il lui manquait simplement un écran.
RésultatUn conseil de classe ou un mot aux parents se prépare depuis un seul onglet, jour par jour.
Annoter toute une classe
Sélectionner les élèves sur le plan, choisir l’annotation, appliquer. Derrière ce geste simple, tout a été réécrit pour qu’une coupure de connexion ne laisse jamais une classe à moitié annotée.
RésultatLa classe est annotée entière, ou pas du tout.
Une salle qui reste comme on l’a dessinée
Le bureau du professeur se recalculait à chaque ouverture : impossible de poser une table à côté. Et un défaut de calcul faisait ressortir des tables droites inclinées de sept degrés, 29 en production. Les deux sont corrigés, et les angles enregistrés remis d’aplomb.
RésultatLe bureau se pose, pivote et garde sa place, et les tables droites restent droites.
Ce qui sert tous les jours, en premier
Le menu mettait six rubriques sur le même plan, alors que deux servent chaque jour, le tableau de bord et le mémo, et quatre se règlent une fois, en début d’année. Le quotidien passe désormais devant, le paramétrage est regroupé dessous, et chaque rubrique s’ouvre directement là où l’on modifie.
Faire venir de nouveaux utilisateurs
Rien à ressaisir pour commencer
Le premier frein à l’adoption d’un nouvel outil, c’est la ressaisie. Les enseignants exportent leur emploi du temps depuis Pronote et le déposent dans Oléo : cours, horaires et alternance des semaines A et B sont reconnus automatiquement, puis relus avant d’être ajoutés. Les listes d’élèves arrivent de la même façon.
Une simple capture d’écran fonctionne aussi : une IA relève ce qui est écrit, puis des règles fixes recalent les horaires sur les vraies sonneries. L’IA ne devine jamais l’alternance des semaines, une erreur à cet endroit créerait des cours fantômes une semaine sur deux, invisibles à la relecture. Savoir où ne pas faire confiance à l’IA fait partie de la conception.
Une mise en route qui ne bloque personne
L’emploi du temps était un passage obligé : impossible de créer une classe ou une salle sans lui. Or, pour se servir d’Oléo, il suffit d’une classe, de ses élèves et d’une salle.
La mise en route devient un assistant en quatre étapes. L’emploi du temps reste proposé en premier, parce qu’un seul import en remplit deux autres, mais « Passer cette étape » est aussi visible que les autres choix, et l’outil s’en souvient.
Un site pour être trouvé, là où il n’y avait qu’un écran de connexion
L’adresse d’Oléo ouvrait directement l’écran de connexion : un enseignant qui en entendait parler n’avait rien à lire avant de créer un compte. J’ai conçu et intégré un site de treize pages, chacune pensée pour une recherche précise : importer depuis Pronote, faire un plan de classe en ligne, placer ses élèves automatiquement, disposer sa salle, annoter.
Le site respecte ses visiteurs autant que l’application respecte ses utilisateurs : aucun cookie, aucun service tiers, une mesure d’audience sans donnée personnelle, et donc pas de bandeau de consentement.
Reprendre votre application, avec la même méthode
Reprendre une application existante, c’est d’abord ne rien casser. Chaque évolution a été préparée séparément, testée sur une copie, puis livrée. Les gains ont été mesurés, pas supposés. Et quand une correction s’est révélée moins bonne que l’existant, elle a été défaite puis refaite autrement.
La mise en production, l’étape la plus délicate, a été préparée comme une étape à part entière : mode d’emploi pas à pas, ordre qui évite toute interruption de service, sauvegarde vérifiée avant de commencer.
Si votre outil ressemble à celui-ci — il rend service, mais plus personne n’ose y toucher — c’est exactement la mission « Moderniser une application existante ».
Reprendre un produit, ce n’est pas le réécrire : c’est rendre chaque évolution plus sûre que la précédente.
Un processus à outiller ?
Parlons de votre application métier.
Montrez-moi comment vous travaillez aujourd’hui : vos fichiers, vos outils et les étapes qui vous font perdre du temps.