Un parent ouvre le site web du district sur son téléphone au moment du ramassage. L'image du héros se bloque. Le menu de navigation ne s'affiche pas. Il ferme Safari après 3,1 secondes — le seuil d'abandon médian de Google. Nous avons audité 50 sites web de districts K-12 le mois dernier. Soixante-seize pour cent tournent sur WordPress Multisite installé entre 2014 et 2017. Score Lighthouse mobile moyen : 41. Coût d'hébergement mensuel moyen : 1 890 $. La plupart paient une agence 11 250 $/mois pour mettre à jour sept sous-sites qui partagent le même pied de page et un seul annuaire du personnel. L'architecture n'a pas changé depuis l'administration Obama, mais les attentes des parents ont changé le jour où ils ont utilisé une application React d'une seule page pour commander des courses. L'architecture multi-tenant Next.js remplace toute la pile pour 30 000 $ — une seule fois — et réduit votre facture d'hébergement à 180 $/mois. Voici la construction.

Métrique Résultat
Exécution de WordPress Multisite 38 (76 %)
Score Lighthouse mobile moyen 41
Plugins moyen par site 23
Recherche fonctionnelle 12 (24 %)
Optimisé pour mobile 18 (36 %)
Conforme à l'ADA 7 (14 %)
Mis à 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 dont 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 de marketing SaaS. C'est une infrastructure publique critique. Quand un parent ne peut pas trouver l'annonce du jour neigeux à 6 h du matin sur son téléphone, c'est un vrai échec avec des conséquences réelles. Quand une famille hispanique ne peut pas trouver la demande de repas gratuit, les enfants ont faim.

Cet article explique exactement pourquoi les sites web K-12 sont bloqués, à quoi ressemble une architecture de remplacement moderne et les chiffres de coûts réels qui rendent le passage évident.

Table des matières

Les sites web des districts scolaires tournent toujours sur WordPress Multisite : La solution à 30 000 $

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

Les sites web des districts scolaires n'échouent pas pour une seule raison. Ils échouent parce que quatre problèmes se composent les uns les autres, et personne n'a la bande passante pour les démêler.

La crise du personnel informatique

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

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

J'ai parlé avec un directeur informatique 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 étaient submergés par les réparations de Chromebooks, les migrations Google Workspace et une frayeur de ransomware 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 périmées restent en direct. L'assistant principal qui a pris sa retraite il y a deux ans est toujours répertorié comme le contact principal. Le menu du déjeuner affiche septembre 2023. Le formulaire d'inscription renvoie à une erreur 404.

Ce n'est pas de la paresse. C'est une crise d'allocation de ressources. Quand vous forcez le personnel informatique à choisir entre garder le réseau en marche 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 programme, 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 de manière condescendante -- je veux dire que l'interface d'administration WordPress a été conçue pour les personnes qui construisent des sites web, pas pour les personnes qui enseignent aux mathématiques de troisième année. L'éditeur Gutenberg, les conflits de plugins, la bibliothèque 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 email à l'informatique
  4. L'informatique a un arriéré de 3 semaines
  5. L'enseignant abandonne
  6. L'enseignant poste tout sur Google Classroom à la place

Maintenant, le site web officiel de l'école est hors de propos par rapport à la communication quotidienne à l'école. Les parents finissent par jongler avec 3-5 applications différentes : le site web de l'école (pour les trucs qui sont encore là), Google Classroom (pour les devoirs réels), ParentSquare (pour les annonces), Remind (pour les messages rapides) et peut-être un groupe Facebook pour faire bonne mesure.

Et ils ne trouvent toujours pas l'horaire des 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 source unique de vérité. Au lieu de cela, c'est l'endroit où personne ne regarde.

La conformité ADA en tant que procès en attente

Celui-ci tient les surintendants éveillés la nuit -- ou 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 action en justice pour l'ADA peut coûter à un district 30 000 $ à 100 000 $ ou plus en frais juridiques et coûts de correction. En 2024, le DOJ a finalisé les règles exigeant spécifiquement que les sites web des gouvernements des États et locaux (y compris les districts scolaires) respectent la conformité WCAG 2.1 niveau AA, avec des délais à partir d'avril 2026 pour les entités plus importantes.

Maintenant, pensez à WordPress Multisite avec 50 sites scolaires. C'est 50 sites potentiellement non conformes. Chacun entretenu 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 l'absence de celles-ci), et des approches différentes de la hiérarchie des titres.

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-tenant vous donne : une base de code conforme signifie que les 50 écoles sont automatiquement conformes. Les composants appliquent l'accessibilité. La structure des titres est correcte par défaut. Les téléchargements d'images nécessitent du texte alternatif. Les PDF sont signalés s'ils ne sont pas balisés. Vous corrigez un problème d'accessibilité une fois, et c'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. Ils ne peuvent pas naviguer dans le processus de demande de déjeuner gratuit et réduit. Ils ne peuvent pas comprendre les itinéraires de transport. Ils manquent les événements, les délais et les opportunités.

Ce n'est pas un plus. 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 avec une maîtrise limitée de l'anglais. Un site web anglais uniquement est un risque de conformité en plus d'être un échec d'équité.

Examinons le coût de corriger cela :

Solution Coût annuel
WPML sur WordPress (50 sites × 199 $/an) 9 950 $/an + coûts de traduction continus
Finalsite Pas de réel support multilingue
Widget Google Translate Imprécis, casse la mise en page, cauchemar ADA
Next.js + next-intl + traduction par lot ~110 $ une seule fois pour 5 langues

Ce chiffre de 110 $ n'est pas une coquille. Avec une application Next.js correctement internationalisée utilisant next-intl, vous extrayez tous les chaînes de contenu, les exécutez via une API de traduction à environ 22 $ par langue, passez en revue avec des locuteurs natifs, et vous avez terminé. 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 brisées, casse la mise en page, crée des problèmes d'accessibilité et -- de manière critique -- 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 pari

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 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 de 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 réellement, d'ailleurs), traduction, mise en cache, sécurité. Notre audit a trouvé une moyenne de 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.
  • Endettement de la version PHP : Beaucoup de ces installations s'exécutent sur des versions PHP qui sont en fin de vie. La mise à jour de PHP risque de casser les plugins. Ne pas mettre à jour PHP est un trou de sécurité.
  • Le désordre de Gutenberg : Le passage de WordPress à l'éditeur de blocs a interrompu 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 lui-même est en train de vieillir.
  • Spirale mortelle des performances : WordPress sert des HTML rendus côté serveur à partir d'une base de données MySQL pour chaque demande. Ajoutez WooCommerce (oui, certaines écoles gèrent des magasins de marchandises), BuddyPress ou tout plugin lourd, et vous regardez 3-5 secondes de temps de chargement. Sur mobile sur une connexion cellulaire dans un parking scolaire ? Oubliez ça.
  • Surface d'attaque de sécurité : WordPress alimente 43 % du web, ce qui en fait la cible #1 pour les attaques automatisées. Un seul plugin compromis sur votre multisite ? Chaque site scolaire est exposé.

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

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

L'alternative que la plupart des districts envisagent est un vendeur 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. Ils gèrent l'hébergement. Ils fournissent des modèles. Ils ont certaines fonctionnalités d'accessibilité. Mais ils 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. Pour toujours. Si vous voulez partir, vous recommencez à zéro -- il n'y a pas d'exportation facile de votre contenu et de votre structure.

Inflexibilité : Vous obtenez ce qu'ils vous donnent. 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 district hébergés par Finalsite. Les scores variaient de 35 à 62 sur mobile. Ce sont essentiellement des sites de marketing -- pages rendues côté serveur avec des bundles JavaScript lourds, des scripts de suivi tiers et des images non optimisées. Ils ne sont pas rapides.

Enfermement : C'est le gros. 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 commutation sont énormes. Ils le savent. C'est le modèle commercial.

Je ne dis pas que ces vendeurs sont mauvais. Ils fournissent un vrai service pour les districts qui n'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 écrasante dans cette direction.

Les sites web des districts scolaires tournent toujours sur WordPress Multisite : La solution à 30 000 $ - architecture

La solution : Architecture multi-tenant Next.js

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

/                          → Page d'accueil du district
/schools/[slug]            → Page d'accueil de l'école (45 écoles)
/schools/[slug]/calendar   → Événements spécifiques à l'école
/schools/[slug]/staff      → Annuaire du personnel
/schools/[slug]/staff/[id] → Page de classe d'enseignant
/[lang]/schools/[slug]     → Version traduite (es, vi, ar, zh, ht)
/portal                    → Portail parent (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 bugs. 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 enseignant

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 programme (éditeur de texte enrichi, pas WordPress Gutenberg)
  • 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 plugins, 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 modifier que leur propre contenu. Pas de supervision d'administrateur nécessaire. Aucun ticket informatique.

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

Portail parent

Les parents s'authentifient et voient une vue personnalisée basée sur leurs enfants inscrits. Itinéraire de bus pour leur enfant. Menu de la cafétéria pour leur école. Événements à venir filtrés aux écoles pertinentes. Coordonnées des enseignants 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 applique WCAG AA. Chaque composant <Image> nécessite du texte alternatif. La hiérarchie des titres est appliquée par le modèle de page. Le contraste des couleurs est validé au moment de la compilation. La gestion de la mise au point est gérée dans les composants de navigation.

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

Cela importe quand vous avez 200 enseignants ajoutant du contenu. Vous ne pouvez pas former 200 personnes à 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 à partir d'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 différente.

Les chiffres qui rendent cela évident

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

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

Le coût d'hébergement Next.js est de 45 $/mois sur Vercel Pro, ou même 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 en cours : première année.

Et voici ce que la colonne de coût WordPress ne capture pas : le temps du personnel informatique. Ces 2-3 personnes informatiques passant 10-15 heures par semaine à éteindre des incendies de site web ? C'est 30 000 $-50 000 $ d'allocation de salaire qui pourraient aller à littéralement n'importe quoi d'autre. Gestion des Chromebooks. Cybersécurité. Dormir réellement toute la nuit.

Le coût de compilation de 60 000 $-100 000 $ pour la plateforme Next.js est un investissement unique. Vous le possédez. Pas de licence annuelle. Pas de frais par école. Pas d'enfermement par le vendeur. Ajouter une 46e école ? C'est une nouvelle entrée dans le CMS, pas un appel de vente.

À quoi ressemble réellement la migration

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

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

  • Inventorier tout le contenu existant sur 45 sites
  • Identifier ce qui est réellement actuel par rapport à ce qui est abandonné
  • Mapper l'architecture d'information
  • Entretiens avec le personnel informatique, les enseignants et les parents sur les points douloureux

Semaines 4-8 : Construction de la plateforme

  • Application Next.js multi-tenant avec intégration CMS sans tête
  • Portail enseignant avec authentification Supabase
  • Bibliothèque de composants avec accessibilité intégrée
  • Configuration i18n avec next-intl
  • Pipeline CI/CD avec tests d'accessibilité automatisés

Semaines 9-12 : Migration de contenu et formation

  • Scripts de migration de contenu automatisés (API REST WordPress → CMS sans tête)
  • Examen manuel du contenu et nettoyage
  • Formation des enseignants (sessions de 30 minutes -- si cela prend plus de temps, l'UX a besoin de travail)
  • Lancement logiciel du portail parent

Semaines 13-14 : Lancement

  • Changement DNS
  • Mappage des redirections (chaque ancienne URL obtient une redirection 301)
  • Surveillance et soutien

Chrono total : 14 semaines. C'est un semestre. Vous pouvez lancer pendant les vacances d'hiver quand le trafic est le 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 magnitude en complexité.

Si votre district explore ce type de migration, nous avons déjà fait ce travail. Contactez-nous et nous pouvons explorer 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 sur 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 vendeurs 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 informatique, hébergement et support de développement. Une compilation Next.js multi-tenant personnalisée coûte 60 000 $-100 000 $ en tant qu'investissement unique avec environ 540 $/an en hébergement. Sur trois ans, la compilation personnalisée est l'option la moins chère de loin -- et vous possédez 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 de plugins, la surface d'attaque de sécurité, la mauvaise performance mobile et l'incapacité à appliquer l'accessibilité sur 50 sites en font un mauvais choix pour les exigences K-12 modernes. Chaque site du réseau peut dériver dans des directions différentes, et avec 2-3 personnel informatique gérant tout le reste du district, personne n'a le temps de le garder à jour. Les districts exécutant WordPress Multisite à partir de 2016 portent une dette technique importante.

Quelles sont les exigences de conformité ADA pour les sites web des districts scolaires ?

Le DOJ a finalisé les règles en 2024 exigeant que les sites web des gouvernements des États et locaux -- y compris les districts scolaires publics -- respectent les normes WCAG 2.1 niveau AA. Les entités plus importantes font face à des délais à partir d'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 contenu ajouté doit maintenir la conformité, c'est pourquoi construire l'application d'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 à 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 $ en utilisant des API 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 précises, correctement formatées et ne cassent pas la mise en page.

Les enseignants peuvent-ils mettre à jour leurs propres pages sans support informatique ?

Oui -- c'est tout le sens 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 programme, publier des devoirs, ajouter des annonces et mettre à jour les coordonnées. Row-Level Security garantit qu'ils ne peuvent modifier que leur propre contenu. Pas de tickets informatique, pas d'arriéré de 3 semaines, pas d'abandon et de 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 le redessinons.

Combien de temps prend la migration d'un site web de district scolaire ?

Pour un district de 45 écoles, prévoir un calendrier de 14 semaines : 3 semaines pour la découverte et l'audit du contenu, 5 semaines pour la construction de la plateforme, 4 semaines pour la migration du 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 du contenu est partiellement automatisée à l'aide de l'API REST WordPress pour extraire le contenu dans le nouveau CMS sans tête, mais un examen manuel et un nettoyage sont nécessaires puisque beaucoup de l'ancien contenu est périmé.

Qu'est-ce qui est mieux pour les sites web scolaires : Finalsite ou une compilation personnalisée ?

Finalsite a du sens pour les districts avec absolument zéro capacité technique et un budget pour les licences continues. Pour les districts qui peuvent investir dans une compilation unique, une plateforme Next.js multi-tenant personnalisée coûte moins sur trois ans (61 000 $-101 000 $ contre 405 000 $-1 080 000 $), offre de meilleures performances (Lighthouse 95+ contre 35-62), offre une propriété complète du contenu et de l'infrastructure, et offre de la flexibilité pour les intégrations personnalisées avec SIS, LMS et d'autres systèmes de district. Le compromis est que vous avez besoin d'un partenaire de développement pour la compilation initiale et le développement continu de 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 JavaScript et CSS à chaque chargement de page. Les pages rendues côté serveur nécessitent une requête de base de données pour chaque demande. Les images sont souvent non optimisées. Il n'y a pas de CDN, ou le CDN est mal configuré. Ajoutez un environnement d'hébergement partagé et vous regardez 3-5 secondes de temps de chargement. Sur une connexion mobile dans un parking scolaire, c'est encore pire. Un site Next.js généré statiquement sert du HTML pré-construit à partir de serveurs de bord du monde entier, se chargeant généralement en moins d'une seconde. Cela importe quand un parent vérifie un jour neigeux à 6 h du matin sur son téléphone.

Les districts scolaires possèdent-ils leur site web s'ils utilisent un vendeur 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'exportation propre de votre contenu, de vos modèles ou de votre configuration. Cet enfermement est intentionnel -- c'est ce qui rend le modèle de revenus récurrents fonctionner. Avec une compilation personnalisée utilisant un CMS sans tête comme Sanity ou Payload, vous possédez chaque 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 mettre le développement en interne sans rien perdre.

Le site web du district est la porte d'entrée de 10 000 familles. Si cette porte ne s'ouvre pas sur un téléphone, ne parle pas leur langue et ne laisse pas les enseignants mettre à jour leurs propres pages -- cela échoue à tous ceux qu'il est censé servir.