Nous avons audité 50 sites web de districts scolaires la semaine dernière. Voici ce que nous avons trouvé :

Métrique	Résultat
Exécution WordPress Multisite	38 (76%)
Score Lighthouse mobile moyen	41
Plugins moyens par site	23
Recherche fonctionnelle	12 (24%)
Optimisé pour mobile	18 (36%)
Conforme ADA	7 (14%)
Mise à jour au cours des 6 derniers mois	22 (44%)

Ce sont les sites web que 5 millions de familles utilisent pour trouver les horaires des bus, les fermetures d'écoles, les menus de la cafétéria et les coordonnées des enseignants. Ils méritent mieux.

J'ai passé la dernière décennie à construire des plateformes web, et je n'ai jamais vu un secteur où l'écart entre ce que les utilisateurs ont besoin et ce qu'ils obtiennent soit aussi large. Les sites web des districts scolaires ne sont pas des magasins de commerce électronique ou des pages marketing SaaS. Ce sont des infrastructures publiques critiques. Quand un parent ne peut pas trouver l'annonce de jour de neige à 6 h du matin sur son téléphone, c'est un vrai échec avec de vraies conséquences. Quand une famille hispanophone ne peut pas trouver la demande de repas gratuit, les enfants ont faim.

Cet article détaille exactement pourquoi les sites web du K-12 sont bloqués, à quoi ressemble une architecture de remplacement moderne, et les mathématiques de coût réelles qui rendent le changement évident.

Table des matières

• Les quatre problèmes qui tuent les sites web K-12
  • La crise du personnel IT
  • L'effondrement de la mise à jour du contenu par les enseignants
  • La conformité ADA comme une bombe judiciaire
  • L'échec de la traduction est une crise d'équité
• Pourquoi WordPress Multisite était le mauvais choix
• Le piège des fournisseurs : Finalsite, Blackboard et SchoolPointe
• La solution : Architecture multi-locataire Next.js
• Les mathématiques qui rendent cela évident
• À quoi ressemble réellement la migration
• FAQ

Les quatre problèmes qui tuent les sites web K-12

Les sites web des districts scolaires ne échouent pas pour une raison. Ils échouent parce que quatre problèmes se renforcent mutuellement, et personne n'a la capacité de les démêler.

La crise du personnel IT

Voici un chiffre qui devrait vous choquer mais ne surprendra personne qui travaille dans l'éducation : l'équipe IT du district scolaire moyen compte 2-3 personnes. Ces 2-3 humains gèrent 20-50 sites web scolaires PLUS l'e-mail, le système d'information scolaire (SIS), le système de gestion de l'apprentissage (LMS), l'infrastructure réseau, et environ 10 000 appareils (Chromebooks, ordinateurs portables d'enseignants, tableaux blancs interactifs, imprimantes).

Il n'y a zéro bande passante pour la gestion du site web. Zéro.

J'ai parlé à un directeur IT d'un district de taille moyenne au Texas l'année dernière. Il m'a dit que son équipe n'avait pas touché à l'installation WordPress Multisite depuis huit mois. Pas parce qu'ils ne s'en souciaient pas -- parce qu'ils se noyaient dans les réparations de Chromebooks, les migrations Google Workspace et une frayeur de rançongiciel qui a mangé trois semaines de la vie de tout le monde.

Le résultat ? Les sites restent non mis à jour pendant des mois. Les liens brisés s'accumulent. Les informations obsolètes restent actives. Le directeur adjoint qui a pris sa retraite il y a deux ans est toujours listé comme le contact principal. Le menu du déjeuner affiche septembre 2023. Le formulaire d'inscription renvoie à une page 404.

Ce n'est pas de la paresse. C'est une crise d'allocation des ressources. Quand vous forcez le personnel IT à choisir entre maintenir le réseau opérationnel et mettre à jour le site web, le site web perd à chaque fois.

L'effondrement de la mise à jour du contenu par les enseignants

Les enseignants veulent mettre à jour leurs pages de classe. Ils le veulent vraiment. Ils veulent publier le syllabus, partager les devoirs et afficher des annonces sur la foire scientifique.

Mais WordPress est trop complexe pour le personnel non technique. Je ne dis pas cela avec condescendance -- je veux dire que l'interface administrateur de WordPress a été conçue pour les personnes qui construisent des sites web, pas pour les personnes qui enseignent les mathématiques en troisième année. L'éditeur Gutenberg, les conflits de plugins, la bibliothèque de médias, le système de taxonomie, l'historique des révisions... c'est beaucoup.

Voici ce qui se passe réellement :

1. L'enseignant essaie de mettre à jour sa page
2. Quelque chose se casse (mauvais modèle, problème de formatage, suppression accidentelle d'un widget)
3. L'enseignant envoie un e-mail à l'IT
4. L'IT a un arriéré de 3 semaines
5. L'enseignant abandonne
6. L'enseignant publie tout sur Google Classroom à la place

Maintenant, le site web officiel de l'école est hors de propos pour la communication quotidienne de l'école. Les parents finissent par jongler avec 3-5 applications différentes : le site web de l'école (pour ce qui y reste encore), Google Classroom (pour les vrais devoirs), ParentSquare (pour les annonces), Remind (pour les messages rapides), et peut-être un groupe Facebook par-dessus le marché.

Et ils ne trouvent toujours pas l'horaire du bus.

Cette fragmentation est frustrante pour les familles. C'est particulièrement brutal pour les parents qui ne sont pas férus de technologie ou qui ont des enfants dans plusieurs écoles du district. Le site web de l'école devrait être la seule source de vérité. Au lieu de cela, c'est l'endroit où personne ne regarde.

La conformité ADA comme une bombe judiciaire

Celle-ci tient les surintendants éveillés la nuit -- ou elle le devrait.

Les districts scolaires sont de plus en plus des cibles de poursuites ADA pour les sites web inaccessibles. Et les règlements ne sont pas bon marché. Une seule poursuite ADA peut coûter à un district 30 000 $ à 100 000 $ + en frais juridiques et coûts de remédiation. En 2024, le DOJ a finalisé des règles exigeant spécifiquement que les sites web des gouvernements d'État et locaux (y compris les districts scolaires) respectent la conformité WCAG 2.1 de niveau AA, avec des délais commençant en avril 2026 pour les entités plus grandes.

Maintenant, pensez à WordPress Multisite avec 50 sites scolaires. C'est 50 sites potentiellement non conformes. Chacun maintenu par une personne différente (ou personne). Chacun avec un ensemble différent de plugins, une configuration de modèle différente, des habitudes de texte alternatif d'image différentes (ou son absence), et des approches différentes de la hiérarchie des en-têtes.

Auditer 50 sites individuellement ? Remédier 50 sites individuellement ? C'est des centaines d'heures de travail. Et cela doit être refait chaque fois que quelqu'un ajoute du contenu, car un enseignant téléchargeant un PDF sans balisage approprié ou une image sans texte alternatif remet la page de cette école hors de conformité.

Voici ce qu'une architecture multi-locataire vous donne : une base de code conforme signifie que tous les 50 écoles sont conformes automatiquement. Les composants imposent l'accessibilité. La structure d'en-tête est correcte par défaut. Les téléchargements d'images nécessitent un texte alternatif. Les PDF sont signalés s'ils ne sont pas balisés. Vous corrigez un problème d'accessibilité une fois, et il est corrigé partout.

L'échec de la traduction est une crise d'équité

Dans les districts scolaires diversifiés, 30-50% des familles parlent une langue autre que l'anglais à la maison. Espagnol, vietnamien, arabe, mandarin, créole haïtien -- cela dépend de la communauté, mais les chiffres sont importants.

Et leurs sites web scolaires ? Anglais uniquement.

Ces familles ne peuvent pas trouver les informations d'inscription. Elles ne peuvent pas naviguer dans le processus de demande de repas gratuit et réduit. Elles ne peuvent pas comprendre les itinéraires de transport. Elles ratent les événements, les délais et les opportunités.

Ce n'est pas un élément symptoMatique. Le titre VI de la Loi sur les droits civiques exige que les districts scolaires recevant un financement fédéral communiquent efficacement avec les parents de compétence limitée en anglais (LEP). Un site web anglais uniquement est un risque de conformité en plus d'être un échec d'équité.

Regardons le coût de corriger cela :

Solution	Coût annuel
WPML sur WordPress (50 sites × 199 $/an)	9 950 $/an + frais de traduction continus
Finalsite	Aucun véritable support multilingue
Widget Google Translate	Inexact, casse la mise en page, cauchemar ADA
Next.js + next-intl + traduction par lot	~110 $ pour 5 langues

Ce chiffre de 110 $ n'est pas une faute de frappe. Avec une application Next.js correctement internationalisée utilisant next-intl, vous extrayez toutes les chaînes de contenu, les exécutez via une API de traduction à environ 22 $ par langue, examinez avec des locuteurs natifs, et c'est fini. Ajoutez une langue au fur et à mesure que votre communauté en a besoin. Le routage gère /es/schools/lincoln-elementary automatiquement.

Le widget Google Translate que la moitié de ces districts utilisent ? Il produit des traductions grammaticalement cassées, casse la mise en page, crée des problèmes d'accessibilité, et -- crucellement -- il ne traduit pas le contenu à l'intérieur des images ou des PDF. C'est un pansement qui signale aux familles : « Nous ne nous en soucions pas assez pour le faire correctement. »

Pourquoi WordPress Multisite était le mauvais choix

Pour être juste, WordPress Multisite n'était pas un choix déraisonnable en 2014-2016. C'était gratuit (ou presque). Il pouvait techniquement exécuter plusieurs sites à partir d'une seule installation. Il y avait un énorme écosystème de plugins. Et les districts pouvaient trouver des développeurs WordPress.

Mais voici ce qui s'est passé au cours de la décennie suivante :

• Prolifération des plugins : Chaque site a accumulé des plugins pour les choses que le noyau ne pouvait pas faire. SEO, formulaires, calendriers, superpositions d'accessibilité (qui ne fonctionnent pas vraiment, d'ailleurs), traduction, mise en cache, sécurité. Notre audit a trouvé en moyenne 23 plugins par site. C'est 23 vulnérabilités de sécurité potentielles, 23 choses qui peuvent entrer en conflit, 23 choses qui ont besoin de mises à jour.
• Dette de version PHP : De nombreuses installations exécutent des versions PHP qui sont en fin de vie. La mise à jour de PHP risque de casser des plugins. Ne pas mettre à jour PHP est un trou de sécurité.
• Le désordre Gutenberg : Le passage de WordPress à l'éditeur de blocs a brisé les flux de travail pour les enseignants qui venaient à peine d'apprendre l'éditeur classique. De nombreux districts exécutent toujours le plugin Classic Editor, qui est lui-même en désuétude.
• Spirale de mort de performance : WordPress sert du HTML rendu côté serveur à partir d'une base de données MySQL pour chaque requête. Ajoutez WooCommerce (oui, certaines écoles gèrent des magasins de marchandises), BuddyPress ou tout plugin lourd, et vous regardez des temps de chargement de 3-5 secondes. Sur mobile via la connexion cellulaire du parking d'une école ? Oubliez-le.
• Surface d'attaque de sécurité : WordPress alimente 43% du web, ce qui le rend la cible #1 des attaques automatisées. Un seul plugin compromis sur votre multisite ? Tous les sites scolaires sont exposés.

WordPress Multisite était le choix pragmatique il y a une décennie. C'est une dette technique maintenant.

Le piège des fournisseurs : Finalsite, Blackboard et SchoolPointe

L'alternative que la plupart des districts envisagent est un fournisseur de site web K-12. Finalsite est le grand nom. Il y a aussi Blackboard (maintenant Anthology), SchoolPointe, Apptegy (Thrillshare) et quelques autres.

Ces plateformes résolvent certains problèmes. Elles gèrent l'hébergement. Elles fournissent des modèles. Elles ont certaines fonctionnalités d'accessibilité. Mais elles s'accompagnent de compromis sérieux :

Coût : Finalsite pour un district avec 45 écoles coûte 135 000 $ à 360 000 $ par an. Ce n'est pas un coût unique. C'est récurrent. Chaque année. Toujours. Si vous voulez partir, vous recommencez à zéro -- il n'y a pas d'export facile de votre contenu et structure.

Inflexibilité : Vous obtenez ce qu'ils vous donnent. Vous avez besoin d'une intégration personnalisée avec votre SIS ? Ce sera un engagement de services professionnels. Vous voulez changer le fonctionnement du calendrier ? Envoyez une demande de fonctionnalité et attendez. Votre district a un programme bilingue unique qui nécessite un routage personnalisé ? Désolé, ce n'est pas dans le modèle.

Performance : J'ai exécuté des audits Lighthouse sur plusieurs sites de districts hébergés par Finalsite. Les scores variaient de 35 à 62 sur mobile. Ce sont essentiellement des sites de marketing -- des pages rendues côté serveur avec de gros paquets JavaScript, des scripts de suivi tiers et des images non optimisées. Ils ne sont pas rapides.

Enfermement : C'est la grosse affaire. Votre contenu vit dans leur CMS. Vos URL sont structurées à leur manière. Votre modèle de données suit leur schéma. Trois ans plus tard, les coûts de changement sont énormes. Ils le savent. C'est le modèle commercial.

Je ne dis pas que ces fournisseurs sont malveillants. Ils fournissent un service réel pour les districts qui ont zéro capacité technique. Mais si vous avez la possibilité d'investir dans une infrastructure que vous possédez, les mathématiques pointent de manière accablante dans cette direction.

La solution : Architecture multi-locataire Next.js

Voici ce que nous construisons réellement. Une application. Déployée une fois. Servante chaque école du district.

/                          → Page d'accueil du district
/schools/[slug]            → Page d'accueil scolaire (45 écoles)
/schools/[slug]/calendar   → Événements spécifiques à l'école
/schools/[slug]/staff      → Répertoire du personnel
/schools/[slug]/staff/[id] → Page de classe de l'enseignant
/[lang]/schools/[slug]     → Version traduite (es, vi, ar, zh, ht)
/portal                    → Portail parents (authentification requise)
/admin                     → Portail de contenu enseignant/personnel

45 écoles = 45 itinéraires programmatiques à partir d'une seule base de code. Un déploiement. Un endroit pour corriger les bogues. Un endroit pour appliquer l'accessibilité. Un endroit pour ajouter des fonctionnalités.

La pile technologique

Framework:     Next.js 15 (App Router)
CMS:           Headless (Sanity ou Payload CMS)
Auth:          Supabase Auth + Row-Level Security
i18n:          next-intl
Hosting:       Vercel (ou Cloudflare Pages)
Search:        Algolia ou Typesense
Accessibility: axe-core en pipeline CI/CD

Portail des enseignants

C'est la pièce qui change tout pour les opérations quotidiennes. Les enseignants se connectent avec leur compte Google du district (SSO via Supabase Auth). Ils voient leur page de classe. Ils peuvent :

• Mettre à jour leur syllabus (éditeur de texte enrichi, pas Gutenberg WordPress)
• Publier des devoirs avec pièces jointes
• Ajouter des annonces
• Mettre à jour les heures de bureau et les coordonnées

C'est tout. Pas de barres latérales, pas de widgets, pas de paramètres de plugin, pas de confirmations « êtes-vous sûr de vouloir mettre à jour ? ». Une interface ciblée qui fait quatre choses bien.

Row-Level Security (RLS) dans Supabase signifie que les enseignants ne peuvent éditer que leur propre contenu. Aucune surveillance administrateur requise. Aucun billet IT.

-- Politique RLS Supabase : les enseignants ne peuvent mettre à jour que leur propre contenu
CREATE POLICY "Teachers can update own content"
  ON class_pages
  FOR UPDATE
  USING (auth.uid() = teacher_id);

Portail parents

Les parents s'authentifient et voient une vue personnalisée en fonction de leurs enfants inscrits. Itinéraire du bus pour leur enfant. Menu du déjeuner pour leur école. Événements à venir filtrés pour les écoles pertinentes. Coordonnées de l'enseignant pour les enseignants actuels de leur enfant.

Plus besoin de fouiller dans 45 sites scolaires pour trouver des informations sur vos trois enfants dans trois écoles différentes.

Accessibilité par défaut

La bibliothèque de composants impose le respect des normes WCAG AA. Chaque composant <Image> exige un texte alternatif. La hiérarchie des en-têtes est appliquée par le modèle de page. Le contraste des couleurs est validé au moment de la compilation. La gestion du focus est gérée dans les composants de navigation.

Nous exécutons axe-core dans le pipeline CI/CD. Chaque demande de tirage reçoit un audit d'accessibilité. S'il échoue, il ne se déploie pas. Point final.

C'est important quand vous avez 200 enseignants ajoutant du contenu. Vous ne pouvez pas former 200 personnes sur l'accessibilité. Vous pouvez construire un système qui rend la non-conformité structurellement impossible.

Performance

Next.js avec génération statique signifie que les pages scolaires sont pré-rendues au moment de la compilation et servies depuis un CDN. Un parent dans le parking de l'école sur une connexion 3G obtient la page en moins d'une seconde. Les scores Lighthouse atteignent régulièrement 90+.

Nous parlons de la différence entre un score Lighthouse de 41 (moyenne WordPress Multisite de notre audit) et 95. Ce n'est pas une amélioration progressive. C'est une expérience complètement différente.

Les mathématiques qui rendent cela évident

Faisons le coût total de possession de trois ans pour un district avec 45 écoles :

Solution	Année 1	Année 2	Année 3	Total 3 ans
Finalsite	135-360 K$	135-360 K$	135-360 K$	405-1 080 K$
WordPress Multisite (maintenir existant)	30-50 K$	30-50 K$	30-50 K$	90-150 K$
Next.js Multi-Tenant (construire + héberger)	60-100 K$ + 540 $	540 $	540 $	61-101 K$

Le coût d'hébergement Next.js est 45 $/mois sur Vercel Pro, ou encore moins sur Cloudflare Pages. C'est 540 $/an pour une plateforme servant 45 écoles. L'hébergement WordPress seul coûte généralement 500-1 500 $/mois pour une installation multisite gérée.

Seuil de rentabilité par rapport à Finalsite : 3-6 mois. Seuil de rentabilité par rapport à la maintenance WordPress continue : première année.

Et voici ce que la colonne de coût WordPress ne capture pas : le temps du personnel IT. Ces 2-3 personnes IT dépensant 10-15 heures par semaine sur les extincteurs de sites web ? C'est 30-50 K$ en allocation de salaire qui pourrait aller à littéralement n'importe quoi d'autre. Gestion des Chromebooks. Cybersécurité. Vraiment dormir une nuit complète.

Le coût de construction de 60-100 K$ pour la plateforme Next.js est un investissement unique. Vous en êtes propriétaire. Aucune licence annuelle. Pas de frais par école. Aucun enfermement par le fournisseur. Ajouter une 46e école ? C'est une nouvelle entrée dans le CMS, pas un appel commercial.

À quoi ressemble réellement la migration

Nous ne voulons pas prétendre que c'est trivial. Migrer 45 sites web scolaires est un projet. Voici comment il se décompose :

Semaines 1-3 : Découverte et audit de contenu

• Inventaire de tout le contenu existant dans 45 sites
• Identifier ce qui est réellement actuel par rapport à ce qui est abandonné
• Mapper l'architecture de l'information
• Entretien avec le personnel IT, les enseignants et les parents sur les points douloureux

Semaines 4-8 : Construction de la plateforme

• Application multi-locataire Next.js avec intégration CMS headless
• Portail enseignant avec authentification Supabase
• Bibliothèque de composants avec accessibilité intégrée
• Configuration i18n avec next-intl
• Pipeline CI/CD avec test d'accessibilité automatisé

Semaines 9-12 : Migration de contenu et formation

• Scripts de migration de contenu automatisés (API REST WordPress → CMS headless)
• Révision et nettoyage manuel du contenu
• Formation des enseignants (sessions de 30 minutes -- si cela prend plus de temps, l'UX a besoin de travail)
• Lancement en douceur du portail parents

Semaines 13-14 : Lancement

• Basculement DNS
• Mappage de redirection (chaque ancienne URL obtient une redirection 301)
• Surveillance et support

Chronologie totale : 14 semaines. C'est un semestre. Vous pouvez lancer pendant les vacances d'hiver quand le trafic est au plus bas.

L'idée clé : vous ne reconstruisez pas 45 sites web. Vous construisez un site web qui sert 45 écoles. C'est une réduction d'ordre de grandeur de la complexité.

Si votre district envisage ce type de migration, nous avons déjà fait ce travail. Contactez-nous et nous pouvons traverser les spécificités pour la taille et les besoins de votre district. Vous pouvez également consulter notre page de tarification pour les fourchettes approximatives des projets comme celui-ci.

FAQ

Combien coûte une refonte de site web de district scolaire ? Cela dépend de l'approche. Les plateformes de fournisseurs comme Finalsite coûtent 135 000 $ à 360 000 $ par an pour un district de 45 écoles. Maintenir un WordPress Multisite existant coûte 30 000 $ à 50 000 $ par an en temps IT, hébergement et support au développement. Une construction Next.js multi-locataire personnalisée coûte 60 000 $ à 100 000 $ comme investissement unique avec environ 540 $/an en hébergement. Sur trois ans, la construction personnalisée est l'option la moins chère de loin -- et vous êtes propriétaire de la plateforme.

WordPress Multisite est-il bon pour les districts scolaires ? C'était un choix raisonnable en 2014-2016, mais c'est devenu un passif. La prolifération des plugins, la surface d'attaque de sécurité, la mauvaise performance mobile et l'incapacité à appliquer l'accessibilité dans 50 sites en font un mauvais choix pour les exigences K-12 modernes. Chaque site du réseau peut dériver dans différentes directions, et avec 2-3 personnels IT gérant tout le reste du district, personne n'a le temps de le maintenir. Les districts exécutant WordPress Multisite à partir de 2016 portent une dette technique significative.

Quelles sont les exigences de conformité ADA pour les sites web des districts scolaires ? Le DOJ a finalisé des règles en 2024 exigeant que les sites web des gouvernements d'État et locaux -- y compris les districts scolaires publics -- respectent les normes WCAG 2.1 de niveau AA. Les entités plus grandes font face à des délais commençant en avril 2026. La non-conformité peut entraîner des poursuites avec des règlements allant de 30 000 $ à plus de 100 000 $ en frais juridiques et remédiation. Le défi clé pour les districts est que la conformité n'est pas une correction unique -- chaque élément de contenu ajouté doit maintenir la conformité, c'est pourquoi construire l'application de l'accessibilité dans la plateforme elle-même est la seule approche durable.

Comment gérez-vous plusieurs langues sur un site web scolaire ? Avec une application Next.js utilisant next-intl, l'internationalisation est intégrée dans la structure de routage. Chaque langue obtient son propre préfixe d'URL (/es/, /vi/, /ar/), ce qui est mieux pour le SEO et l'accessibilité qu'un widget Google Translate. La traduction de contenu pour 5 langues coûte environ 110 $ à l'aide d'APIs de traduction avec révision par des locuteurs natifs. Comparez cela à WPML sur WordPress à 199 $/an par site (9 950 $/an pour 50 sites), et les économies sont dramatiques. Plus important encore, les traductions sont exactes, correctement formatées et ne cassent pas la mise en page.

Les enseignants peuvent-ils mettre à jour leurs propres pages sans support IT ? Oui -- c'est tout l'intérêt du portail enseignant. Les enseignants s'authentifient avec leur compte Google du district, voient un éditeur simplifié pour leur page de classe, et peuvent mettre à jour leur syllabus, publier des devoirs, ajouter des annonces et mettre à jour les coordonnées de contact. Row-Level Security garantit qu'ils ne peuvent éditer que leur propre contenu. Aucun billet IT, aucun arriéré de 3 semaines, aucune abandon et publication de tout sur Google Classroom à la place. Si l'interface d'édition nécessite une session de formation plus longue que 30 minutes, nous considérons cela comme un échec UX et la repensons.

Combien de temps faut-il pour migrer un site web de district scolaire ? Pour un district de 45 écoles, prévoyez une chronologie de 14 semaines : 3 semaines pour la découverte et l'audit de contenu, 5 semaines pour la construction de la plateforme, 4 semaines pour la migration de contenu et la formation, et 2 semaines pour le lancement. Le meilleur moment pour lancer est pendant les vacances d'hiver ou d'été quand le trafic du site web est le plus bas. La migration de contenu est partiellement automatisée à l'aide de l'API REST WordPress pour extraire le contenu dans le nouveau CMS headless, mais une révision et un nettoyage manuels sont nécessaires car une grande partie de l'ancien contenu est obsolète.

Quel est le mieux pour les sites web scolaires : Finalsite ou une construction personnalisée ? Finalsite a du sens pour les districts ayant absolument zéro capacité technique et budget pour les licences continues. Pour les districts pouvant investir dans une construction unique, une plateforme multi-locataire Next.js personnalisée coûte moins sur trois ans (61-101 K$ vs 405-1 080 K$), fonctionne mieux (Lighthouse 95+ vs 35-62), offre la propriété complète du contenu et de l'infrastructure, et fournit la flexibilité pour les intégrations personnalisées avec SIS, LMS et autres systèmes de district. Le compromis est que vous avez besoin d'un partenaire en développement pour la construction initiale et le développement continu des fonctionnalités.

Pourquoi les sites web des districts scolaires sont-ils si lents sur mobile ? La plupart des sites de district exécutent WordPress avec 20+ plugins, chacun ajoutant du JavaScript et CSS à chaque chargement de page. Les pages rendues côté serveur exigent une requête de base de données pour chaque requête. Les images ne sont souvent pas optimisées. Il n'y a pas de CDN, ou le CDN est mal configuré. Ajoutez un environnement d'hébergement partagé et vous recherchez des temps de chargement de 3-5 secondes. Sur une connexion mobile dans le parking d'une école, c'est encore pire. Un site statiquement généré Next.js sert du HTML pré-construit à partir de serveurs de bord dans le monde entier, se chargeant généralement en moins d'une seconde. C'est important quand un parent vérifie un jour de neige à 6 h du matin sur son téléphone.

Les districts scolaires possèdent-ils leur site web s'ils utilisent un fournisseur comme Finalsite ? Non. Votre contenu vit dans leur CMS, structuré selon leur modèle de données, hébergé sur leur infrastructure. Si vous décidez de partir, vous recommencez essentiellement à zéro. Il n'y a pas d'export propre de votre contenu, modèles ou configuration. Cet enfermement est intentionnel -- c'est ce qui rend le modèle de revenus récurrents fonctionner. Avec une construction personnalisée utilisant un CMS headless comme Sanity ou Payload, vous possédez chaque élément de contenu, chaque ligne de code et chaque configuration de déploiement. Vous pouvez changer les fournisseurs d'hébergement, modifier votre framework front-end ou confier le développement en interne sans rien perdre.

Votre site web de district scolaire est la porte d'entrée pour 10 000 familles. Si cette porte d'entrée ne s'ouvre pas sur un téléphone, ne parle pas leur langue et ne permet pas aux enseignants de mettre à jour leurs propres pages -- c'est un échec pour tout le monde qu'il est censé servir.