Migration pas à pas

La façon sûre de migrer est progressive. Votre site web public continue de fonctionner sans changement pendant que vous connectez et vérifiez chaque partie dans Development.

Les règles qui garantissent la sécurité

• Le design ne doit pas changer. Chaque page doit avoir un aspect identique, qu’Atlas ait ou non du contenu pour elle.
• Le contenu de repli est obligatoire. Si Atlas est injoignable ou n’a rien de publié pour une page, le site sert son contenu intégré.
• Du texte, jamais du HTML. Les valeurs du CMS sont affichées comme du texte ou via vos composants.
• Development d’abord. Rien n’atteint Production tant qu’une release n’a pas passé ses vérifications et qu’une personne ne l’a pas approuvée.

Étape 1 : connecter une page (environ une journée)

1. Créez le site dans Studio et rédigez un contrat minimal avec un type de page.
2. Suivez Connecter un site Next.js.
3. Publiez cette page dans Development et comparez-la à la page en production.

Terminé lorsque la page est rendue depuis Atlas, a le même aspect, et fonctionne toujours avec Atlas désactivé.

Étape 2 : modéliser tout le site

1. Listez chaque route servie par le site et associez-la à un type de page.
2. Rédigez le bundle de contrat : composants avec champs typés, types de pages avec leurs régions, collections, profils de médias et éléments globaux d’en-tête et de pied de page. Conservez-le dans votre dépôt sous atlas/contract.bundle.json.
3. Validez-le et proposez-le. Un administrateur du site l’active dans Studio (Site setup).
4. Refactorez chaque composant de page pour que les sections Atlas décident de l’ordre et du contenu, avec les données intégrées comme repli.

Terminé lorsque Studio indique que le site web est In sync with the active contract.

Étape 3 : déplacer le contenu et les images

1. Téléversez les images avec le bon profil de média. Ne les étirez ni ne les agrandissez jamais ; listez celles qui ne conviennent pas.
2. Créez des entrées pour chaque élément répétitif, en référençant les images par identifiant d’asset, avec un texte alternatif.
3. Renseignez les éléments globaux d’en-tête et de pied de page avec le contenu actuel.
4. Créez une page pour chaque route à partir de son type de page et ajustez ses sections jusqu’à ce que le brouillon corresponde à la page actuelle.
5. Rédigez les traductions en brouillon et faites-les relire par un locuteur natif.

Un agent de code IA connecté via MCP peut en faire la majeure partie sous forme de brouillons. Une personne vérifie chaque page avec Preview on website et la publie.

Étape 4 : rafraîchissement, SEO et redirections

• Ajoutez le récepteur de webhook pour que la publication mette à jour le site en quelques secondes.
• Lisez les titres SEO, les descriptions et noindex depuis l’API Delivery, et construisez le sitemap à partir de /routes.
• Chargez /redirects et appliquez-les, afin que les anciennes URL conservent leur référencement.

Étape 5 : mise en production

1. Formez les éditeurs à Studio, aux brouillons, à l’aperçu et à la publication.
2. Construisez une release. Atlas vérifie que le contrat est synchronisé, qu’il n’y a aucun problème de publication, que le site web est en bonne santé et qu’une sauvegarde est récente.
3. Une personne disposant des droits d’approbation l’approuve. Un administrateur du site active Production et vous créez un jeton de diffusion Production.
4. Déployez votre site web avec le jeton Production. Conservez le contenu de repli en place.

Ce que sert Production

Production sert le contenu, les formulaires, les chatbots et les paramètres de recherche de sa release live. L’aperçu reste réservé à Development. Suivez Mise en production pour connaître les étapes exactes.

Revenir en arrière

• Une erreur de contenu : revenez à une révision antérieure, ou à une release Production antérieure.
• Une erreur de code : redéployez votre build précédent du site web, comme vous le faites aujourd’hui.
• Atlas indisponible : le contenu de repli sert le contenu intégré jusqu’au retour d’Atlas.