Atlas App

Un classement qui s'explique, critère par critère

La plupart des annuaires de professeurs trient par date d'inscription ou par abonnement payé. Atlas App fait l'inverse : la matière est un filtre — un professeur qui ne l'enseigne pas n'apparaît jamais — et tout le reste est un score sur 100 points, réparti sur huit critères pondérés.

Le niveau pèse 30 points parce qu'un excellent professeur de collège n'est pas un professeur de terminale. La zone pèse 20 points : la distance est le premier motif d'abandon d'un cours à domicile. Viennent ensuite le budget (14), le format présentiel ou en ligne (12), les disponibilités (10), l'expérience (8), la vérification du profil (4) et le cours d'essai offert (2).

Deux règles font toute la différence à l'usage. D'abord, un critère que la famille n'a pas renseigné ne pénalise personne : il sort du calcul au lieu de produire un classement arbitraire à partir d'un formulaire volontairement court. Ensuite, chaque résultat porte ses motifs et ses réserves en toutes lettres — « Enseigne le niveau 2ᵉ Bac SM », « Intervient à Agdal », « N'a pas déclaré ce niveau ». Une recommandation qu'on ne peut pas justifier n'inspire pas confiance, et une famille qui ne comprend pas le classement appelle le centre pour le refaire à la main.

• La matière filtre, les sept autres critères notent — jamais l'inverse
• Critère non renseigné = critère ignoré, pas critère pénalisant
• Profil incomplet noté à demi plutôt qu'exclu : sinon les nouveaux professeurs sont invisibles
• Le cours en ligne annule la contrainte de zone, et le score le dit
• Les résultats s'affichent AVANT de demander le téléphone de la famille
• Le navigateur ne reçoit jamais les coordonnées des professeurs — le classement est calculé côté serveur

Tout ce que la famille demandait par téléphone, dans une page

Un centre de soutien passe ses journées à répondre aux mêmes questions : est-ce qu'il est venu, qu'est-ce que je dois encore, où en est-il, quand est-ce que je paie. L'espace parents d'Atlas App répond aux quatre sans qu'on décroche.

Le parent se connecte et voit l'assiduité réelle de son enfant — absences justifiées et non justifiées distinguées, dernière présence datée —, l'état exact de ses mensualités (total, remise, payé, reste à payer, mois impayés), ses bulletins mensuels téléchargeables en PDF, les polycopiés qui lui ont été attribués, ses emprunts à la bibliothèque avec la date de retour, son emploi du temps et les commentaires des enseignants.

Le détail qui change le comportement : chaque échéance porte son propre compte à rebours. Pas un seul compteur sur la mensualité, mais un par échéance — la mensualité, l'abonnement bibliothèque, le retour d'un livre. Ce sont précisément les dates qu'on oublie faute de les voir.

• Assiduité : justifiées et non justifiées séparées, dernière présence datée
• Finances : total, remise, payé, reste, nombre de mois impayés, devise
• Bulletins mensuels en PDF, générés à la demande et jamais stockés en clair
• Polycopiés attribués, téléchargeables depuis la même page
• Bibliothèque : livres lus, abonnement, emprunts en cours et dates de retour
• Un compte à rebours par échéance, pas un compteur global
• Reçus de paiement en PDF, accessibles sans passer par le secrétariat

Un avis, un numéro de téléphone vérifié

Un annuaire de professeurs vaut ce que valent ses avis. Ceux d'Atlas App ne se déposent pas librement : le parent saisit son nom, sa note, son commentaire et son numéro marocain, reçoit un code à six chiffres sur WhatsApp, et l'avis n'est publié qu'une fois ce code validé.

Les garde-fous sont dans le code, pas dans une charte : cinq essais maximum, code expirant, un seul avis vérifié par couple numéro/professeur, HTML retiré du commentaire, commentaire d'au moins dix caractères, limiteur de débit sur la route d'écriture.

Enfin, les deux notations sont reliées. Un avis vérifié compte aussi comme un vote dans la note principale du professeur, celle qui s'affiche en haut de sa fiche et pilote le classement de l'accueil. Sans ce lien, la même fiche affichait deux moyennes différentes à deux endroits — le genre d'incohérence qui coûte plus cher que l'absence de note.

• Code à 6 chiffres envoyé sur WhatsApp avant publication
• 5 tentatives maximum, puis nouveau code obligatoire
• Un seul avis vérifié par numéro et par professeur
• La moyenne est recalculée depuis les votes, jamais incrémentée — un compteur dérive, un recalcul non
• Avis vérifié et note en étoiles alimentent la même moyenne

Le calculateur du bac marocain, avec les vrais coefficients

Au printemps, la requête la plus tapée par les lycéens marocains est le calcul de leur moyenne du baccalauréat. Les sites qui la captent sont des blogs : ils répondent, mais ne peuvent proposer aucun cours derrière. Atlas App répond ET propose.

La formule officielle est appliquée telle quelle — 25 % de contrôle continu, 25 % d'examen régional, 50 % d'examen national — sur les sept filières, chacune avec ses propres coefficients d'examen national. C'est exactement le point que les élèves ignorent : une même matière peut peser 9 dans une filière et 3 dans une autre, et beaucoup répartissent leurs révisions à l'aveugle.

Le barème est codé à un seul endroit du produit. Un calculateur et un simulateur qui donneraient deux résultats différents pour le même élève détruiraient la confiance dans l'outil en une seule visite.

• 7 filières couvertes, coefficients de l'examen national par filière
• Examen régional de 1ʳᵉ année pris en compte : un quart de la note finale, appris trop tard par beaucoup
• Barème centralisé — un seul jeu de constantes pour tous les écrans
• Trois adresses redirigées vers la page canonique (calculateur, simulateur, calcul de moyenne)

Le CV se lit tout seul, le candidat ne ressaisit rien

Un centre qui recrute perd la moitié de ses candidats sur le formulaire. Atlas App renverse l'ordre : le professeur dépose son CV, le serveur le lit, et le formulaire arrive déjà rempli — identité, diplôme le plus élevé, établissement, années d'expérience, matières, ville, et jusqu'à la photo du CV lorsqu'il y en a une. Le candidat corrige au lieu de saisir.

Le texte extrait ne sert pas qu'au pré-remplissage : il est indexé. Côté centre, une recherche approfondie retrouve « agrégation » ou « mission française » dans le corps du CV même si aucun champ du formulaire ne le mentionnait. Un fichier déposé par un candidat est supprimé du disque dès la lecture terminée, réussie ou non.

• Dépôt du CV, lecture serveur, formulaire pré-rempli — puis correction humaine
• Photo du CV récupérée quand elle existe
• Texte du CV indexé : la recherche approfondie du centre fouille le document, pas seulement les champs
• Fichier effacé du disque immédiatement après lecture, y compris en cas d'échec
• Limiteur de débit dédié à la route de lecture : elle coûte cher, elle est protégée

Les pages locales se fabriquent depuis les professeurs réels

Une plateforme de mise en relation ne se fait pas trouver avec une page de recherche : personne ne tape « recherche de professeur », on tape « prof de maths à Agdal ». Atlas App construit donc ses pages locales à partir des profils effectivement publiés : chaque couple matière × ville couvert par au moins un professeur devient une adresse « cours particuliers de {matière} à {ville} », avec les professeurs correspondants déjà classés dessus.

La règle inverse compte autant : une combinaison que personne ne couvre ne produit pas de page vide, elle redirige. Servir des pages sans contenu réel dégrade le référencement du site entier — c'est le piège classique des annuaires générés en masse.

S'y ajoutent une page par requête d'achat (les comparaisons face aux logiciels étrangers, les modules phares, les guides), les tarifs publiés en clair là où tout le marché renvoie à un formulaire, et une page saisonnière de rentrée qui sert les trois publics — familles, professeurs, gérants de centres — et les maille entre eux.

• Une page par couple matière × ville réellement couvert, jamais davantage
• Combinaison non couverte : redirection, pas page vide
• Sitemap trilingue généré à la volée, avec alternates hreflang et x-default
• Anciennes adresses conservées en 301 : couper une URL indexée, c'est perdre l'acquis
• Balisage Schema.org (fil d'Ariane, FAQ, organisation) émis avec la page, pas ajouté après coup
• Tarifs affichés publiquement — aucun concurrent marocain ne le fait

Trois langues, trois index — pas un sélecteur

Beaucoup de sites marocains « multilingues » changent de langue avec un bouton et gardent une seule adresse. Pour un moteur de recherche, ce site n'a qu'une version : les deux autres langues n'existent pas.

Atlas App monte l'intégralité de ses pages sous un préfixe de langue. Chaque page existe donc à trois adresses indexables, chacune déclarant ses équivalentes en hreflang, avec un x-default. La langue est lue dans l'URL et non dans le navigateur : c'est ce qui permet au serveur de produire directement la bonne version, alors qu'une préférence stockée côté navigateur n'existe pas encore au moment où il répond — et n'existe jamais pour un robot.

L'arabe n'est pas une traduction posée sur une mise en page latine : le document bascule en droite à gauche, typographie comprise, et les composants sensibles au sens de lecture — flèches, timelines, curseurs — sont retournés avec lui.

• Français, arabe et anglais, chacun à sa propre adresse indexable
• hreflang fr-MA / ar-MA / en + x-default sur chaque entrée du sitemap
• Langue lue dans l'URL, pas dans le navigateur — condition du rendu serveur correct
• Arabe en droite à gauche complet, y compris les composants directionnels
• Anciennes adresses sans langue redirigées en 301 vers leur équivalent français

Rendu serveur, pages découpées, cache devant

Une plateforme de mise en relation qui met trois secondes à afficher sa première ligne perd sa famille avant son premier résultat. Atlas App est rendu côté serveur : le visiteur reçoit le HTML de la page demandée, lisible immédiatement, et seul le morceau de JavaScript de cette page est ensuite hydraté.

Ce découpage n'est pas cosmétique. Importées en dur, les pages du site partaient dans un unique paquet de 984 ko que le visiteur téléchargeait en entier pour lire l'accueil ; le budget de production refusait d'ailleurs de compiler. Chaque page est donc chargée à la demande.

Devant le serveur de rendu, un cache nginx sert les pages déjà calculées avec des durées de validité adaptées à chaque famille d'adresses, et continue de servir la dernière version connue si l'application redémarre. En production, le rendu tourne en grappe sur deux instances.

• Rendu serveur intégral : contenu lisible avant l'arrivée du JavaScript
• Une page = un morceau chargé à la demande (le paquet unique de 984 ko a été supprimé)
• Cache nginx devant le rendu, validités par famille d'adresses, service dégradé en cas de redémarrage
• Deux instances en grappe, redémarrage sans coupure
• Une animation d'apparition ne masque jamais durablement un contenu : trois filets de sécurité, dont un délai maximal