Liste de contrôle de migration

Utilisez cette liste lors d’une séance de planification avec la personne qui a construit votre site web actuel. Un « non » n’est pas un blocage en soi. Il vous montre où se situe le travail.

1. Technologie

• Le site est en Next.js App Router, ou l’équipe accepte un effort supplémentaire pour un autre framework serveur. (Pourquoi)
• Le contenu peut être récupéré dans du code serveur, et le jeton de diffusion peut résider dans une variable d’environnement serveur.
• Le site peut conserver un contenu de repli intégré pour chaque page déplacée, afin de continuer à fonctionner si Atlas est injoignable.
• L’équipe peut ajouter une route pour l’aperçu, une pour les webhooks, et un rapport de build au démarrage.

2. Design et composants

• Les pages sont composées de sections réutilisables (hero, cartes, FAQ, appel à l’action). Les pages uniques peuvent aussi être un seul composant avec des champs.
• Vous avez listé chaque type de page : accueil, produit, article, page d’atterrissage, mentions légales, etc.
• Pour chaque section, vous savez quelles parties les éditeurs modifient (textes, images, liens, listes) et lesquelles restent fixes dans le code.
• Les éléments interactifs (calculateurs, configurateurs, cartes, animations) restent dans votre code. Les éditeurs ne renseignent que leurs textes et leurs paramètres.

3. Contenu de votre CMS actuel

• Vous pouvez exporter les pages, les entrées et les images : dump de base de données, API, CSV, ou agent IA qui lit l’ancien site.
• Le contenu répétitif (produits, actualités, équipe, implantations) correspond à des collections.
• Vous avez listé les champs personnalisés et connaissez leurs types : texte, texte enrichi, nombre, date, lien, image, référence, liste.
• Vous savez où le CMS actuel exécute du code dans le contenu : shortcodes, embeds, blocs HTML, scripts. Chacun nécessite un composant de remplacement. Voir Faire correspondre votre CMS actuel.
• Vous disposez d’une liste d’URL et de redirections à conserver, afin de ne pas perdre votre référencement.
• Les langues et leurs règles de repli sont claires. Les langues s’écrivant de droite à gauche nécessitent la prise en charge de dir="rtl" dans vos composants.

4. Fonctionnalités dont dépend votre site

Vérifiez chacune d’elles dans l’état des capacités avant de vous engager :

• Formulaires et e-mails de leads : Development et site web live (en relecture finale avant la sortie).
• Chatbot : Development et site web live (en relecture finale avant la sortie).
• Envoi des leads vers un CRM ou un autre système : l’envoi vers un CRM et la Leads API ne couvrent aujourd’hui que les leads Development ; les leads du site web live vous parviennent par les webhooks.
• Statistiques : Atlas compte les pages vues par route, sans cookies, dans Development et sur le site web live. Conservez vos outils de statistiques existants.
• Recherche sur votre site : Atlas ne fournit pas de recherche de site. Conservez la vôtre, ou construisez-la à partir de l’API des entrées.
• E-commerce, paiement, connexions des membres : ne font pas partie d’Atlas. Ils restent dans votre code ou vos services existants.
• Publication planifiée, traductions, redirections, champs SEO : pris en charge.

5. Personnes et approbations

• Vous savez qui édite, qui relit et qui approuve les releases Production.
• Toute personne qui se connecte peut utiliser la connexion d’Atlas. L’authentification unique avec votre propre fournisseur d’identité n’est pas disponible.
• Les responsables juridiques et sécurité ont lu Sécurité et les points ouverts de la FAQ.

Résultat

• Majoritairement oui : suivez la migration pas à pas.
• Plusieurs non dans les sections 1 à 3 : commencez par un pilote sur un type de page.
• Votre site dépend d’éléments de la section 4 qui ne sont pas disponibles : attendez, ou gardez ces parties en dehors d’Atlas pour le moment.