Suivi du développement

• Pas de menu Videos, White Papers conservé; ajouter un filtre vidéo dans Insights, typologie CMS à mapper.
• Migration : Insights avec visites plus publications depuis le 05/05, lot récent annoncé de 213 Insights et 20 Keyplays; vérifier année/borne/volumes et dédupliquer.
• Insights par langue ou par pays : décision toujours attendue. Les 50 Use Cases seront traduits en quatre langues; ne pas étendre cette validation à tous les Insights.

Sélection des Insights les plus utilisés par pays via Search Console; suggestion par IP confirmée. Pas de traduction générale dans plusieurs langues pour le moment.

• Langue choisie et pays indépendants. Proposition Erwan : au Brésil sur /fr, afficher du français, éventuellement regroupé France/Canada; sur /en, contenus anglais Worldwide en priorité.
• Autre piste : traduire un socle tagué Worldwide dans les quatre langues. Exception ciblée encore en réflexion, pas un lancement de traduction.
• À décider : contenus locaux éligibles hors pays, fallback sans résultat/IP inconnue et langue initiale selon pays. Le site actuel utilise Accept-Language à la racine et conserve toute URL linguistique explicite.

Proposition Erwan : jusqu’à 100 articles les plus cliqués par ancien pays/marché, volume ajustable.

• Sélection Search Console par clics, puis dédoublonnage entre marchés et contrôle des typologies. Export fourni : 615 URL Insights, 603 slugs distincts, toutes typologies confondues; inventaire non exhaustif.
• Pour N articles uniques : 4N versions linguistiques et environ 3N traductions nouvelles si la source est conservée. Exemple : 100 articles uniques = 400 versions, environ 300 traductions; ce calcul ne préjuge pas du nombre de pays ni du volume final.
• Recommandation : pilote de 10 à 20 articles avant estimation du lot complet. Les contenus plus anciens pourront être repris ensuite.

• Proposition : Blog post vers Insight/article; ancien Event vers Event, selon inscription ou contenu éditorial lié à l’événement; vidéo vers Video.
• Customer Story / Keyplay : appellation publique Use Case confirmée; mapper le modèle cible selon le contenu. Contrôler les données avant migration : le nom historique Insight ne détermine pas le modèle cible.

Décision Baptiste du 6 novembre : White Papers reste au menu; aucune entrée Videos, confirmé par Christophe.

• Ajouter un filtre vidéo dans Insights; vérifier la correspondance avec la typologie CMS. Les contenus vidéo restent disponibles.
• Aligner navigation, libellés, cartes, listing/routes et parcours de téléchargement/formulaire. Réutilisation du template Insight; rendu et accès à préciser selon le contenu.
• Décision enregistrée; mise en œuvre et recette encore à réaliser.

• Country apparaît dans les maquettes, actuellement désactivé dans l’index. À valider : marché concerné, lieu, ancien découpage à retirer ou autre usage. Site global ne signifie pas absence de ciblage géographique; pays et langue restent distincts.
• Proposition de mapping : Industries vers Industries; Departments vers Business Functions; partenaires technologiques vers Technologies. Relation Services absente du modèle Insight actuel : à définir.
• Valider les correspondances et les règles de sélection des pastilles, distinctes des relations structurées utilisées par les filtres.

• Slugs traduits : adapter leur localisation CMS et le routage. Associer les versions linguistiques du même contenu.
• Préparer ancienne URL complète vers nouvelle URL, redirections permanentes, canonical, hreflang, sitemap et liens internes. Plusieurs pays peuvent partager un contenu : ne pas déduire les redirections du seul slug.
• Préproduction toujours non indexable par les moteurs. L’index éditorial Insights ne constitue pas une ouverture de l’indexation Google.

• Proposition : index automatique des contenus publiés par langue approuvée, Featured éditorial et suggestions de même langue. Première implémentation locale réalisée sur le lot pilote.
• À valider : champs obligatoires à la publication — image, auteur, classifications, résumé. Pastilles pertinentes; layout adapté aux champs facultatifs absents.

• Proposition : FAQ éditoriale facultative, propre au contenu. Formulaire générique partagé dans le CMS, remplaçable par article.
• À valider : présence systématique du formulaire, objectif, champs, destination HubSpot, téléchargements et règles de traitement des données. Séparer son affichage de celui de la FAQ.
• L’envoi du formulaire est actuellement désactivé; raccordement HubSpot et recette à réaliser.

• Définir les responsables de validation des textes, éventuelles traductions ciblées, médias et classifications; fixer la source éditoriale de référence.
• Organiser les corrections entre langues et la coexistence avec les anciens sites encore actifs; distinguer migration initiale et synchronisation récurrente.

Sur un site global, comment montrer les événements pertinents aux visiteurs des différents pays ? Langue de navigation et pays ciblé sont deux critères distincts.

• Proposition : index Events global avec filtre pays visible, modifiable et option Tous les pays. Commencer par Tous les pays et un choix manuel; aucune personnalisation géographique automatique validée.
• Événements physiques : renseigner pays, ville et éventuels marchés ciblés dans le CMS. Événements en ligne : préciser langue réelle, fuseau horaire, audience internationale ou marchés concernés.
• Si un pays est choisi, proposer les événements physiques de ce pays et les événements en ligne pertinents. Ne pas déduire le pays de la langue du site; un visiteur francophone peut chercher un événement en Espagne.
• Option ultérieure à arbitrer : suggérer un pays à partir de la géolocalisation IP, sans imposer le filtre. Détection potentiellement inexacte ou utilisateur en déplacement; choix explicite prioritaire, possibilité permanente de voir tous les pays.
• À valider : affichage initial global ou suggestion géographique, règles des événements internationaux, traduction des fiches, indication de la langue réelle et sélection Featured globale ou adaptée au pays.
• Impacts techniques à cadrer après arbitrage : champs CMS de localisation/audience, règles de filtrage et de classement, cohérence des Featured et mémorisation éventuelle du choix utilisateur. Ne pas activer automatiquement une fonction de géolocalisation sur la base de cette proposition.

Supprimer Customer Stories comme appellation publique. Le renommage du site et les routes/redirections restent à implémenter.

• Utiliser Use Cases dans navigation, titres, cartes et listes. La décision de vocabulaire ne supprime pas les données client, preuves et autorisations.
• Préciser la composition des variantes et les URL finales lors du mapping; ne pas supprimer aveuglément modèles ou contenus historiques.

https://content-web.keyrus.pro/use-cases.html — Erwan confirme que cette liste sert à sélectionner les contenus à migrer.

• Lecture navigateur du 6 novembre : 421 Keyplays, 50 Suggested affichés, 0 Launch, 421 Not sorted. La source désignée et ses statuts sont deux informations distinctes : figer les IDs du lot retenu et réconcilier le marquage avant exécution.
• Retrouver les contenus CMS; reprendre les pays d’origine et de destination comme pays d’éligibilité, dédoublonnés. Convertir les anciennes zones régionales via une correspondance explicite, sans deviner les codes pays.
• Suggérer les Use Cases correspondant au pays détecté par IP. Langue demandée et pays restent indépendants; Karen valide la traduction des 50 Use Cases en EN/FR/ES/PT (update du 6 novembre); organiser la relecture. Le fallback quand une traduction manque reste à définir.
• Adapter les filtres aux maquettes et aux vraies données; signaler les champs sans correspondance et compléter le CMS si nécessaire. Les filtres du tableau de sélection ne sont pas automatiquement ceux du futur site.
• Contrôler droits client, médias et résultats dans les sources; certaines suggestions affichent une permission de citation non renseignée. Aucun contenu fictif ni résultat inventé.

Les vidéos en lecture automatique sur plusieurs pages, notamment la homepage, augmentent les données transférées et peuvent générer des frais de bande passante selon le trafic, le poids des fichiers, les quotas et le fournisseur de diffusion.

• À discuter avec Baptiste : fréquence et emplacement des vidéos en autoplay, poids acceptable et budget de diffusion. Aucun surcoût mesuré ou montant établi à ce stade.
• Évaluer les volumes réellement téléchargés, le trafic attendu, les lectures répétées, le cache et les limites du service média; distinguer stockage et bande passante.
• Propositions à étudier : compression, formats/résolutions adaptés, chargement au moment utile, poster et lecture à la demande lorsque pertinent. Arbitrer l’expérience souhaitée avant modification.

13 formulaires sur 12 pages réutilisent le formulaire HubSpot principal. Huit références CMS étendues, Contact conservé; aucune modification HubSpot.

• Six champs requis : prénom, nom, email professionnel, téléphone, entreprise et message. Poste absent du contrat existant, sans propriété CRM inventée.
• Sept champs masqués : pays IP, URL contenant le slug, source Website, trois qualifications et gclid. Pays inconnu ou non couvert laissé vide, sans déduction depuis la langue.
• Libellés et légal dans keyrus-ai, quatre langues; variantes graphiques conservées. TypeScript, tests attribution et contrôles locaux passent, mais aucun lead réel envoyé.

Erwan demande une campagne complète ultérieure. Le raccordement technique ne valide ni les soumissions ni la réception CRM. Recette obligatoire avant mise en production.

• Tester chaque instance, dont les deux formulaires Event, dans les quatre langues, sur desktop/mobile et navigateurs cibles; vérifier clavier, libellés et liens légaux.
• Champs requis, valeurs invalides/longues/accentuées, consentement et CAPTCHA : validation, refus et expiration.
• Réception CRM, propriétés visibles/cachées, URL/slug, gclid présent/absent, routage, workflows et notifications; confirmation Event.
• Pays IP Netlify couvert/inconnu/non couvert et langue différente du pays; compléter la liste CRM ou valider un routage pour les pays manquants.
• Succès/erreur réseau, nouvelle tentative, double clic/doubles leads, navigation/rechargement, coexistence des instances et redirection vidéo uniquement après succès.
• Corriger les anomalies et retester avant validation Erwan. reCAPTCHA en erreur localement; aucune soumission réelle ni déploiement effectué.

Nouvelle maquette de détail partenaire disponible : 300:21128, exemple Anaplan. Intégration à faire.

• Créer le template avec cinq filtres de ressources et contenu CMS; réconcilier la liste 44/45 partenaires avant import.
• Point 3 : Why Keyrus et les trois services accessibles, menu et catalogue V2 des quatre Capabilities intégrés (24 lignes). Premières versions : textes détaillés Services, sections/médias spécifiques, traductions et validation artistique encore attendus. FAQ métier au point suivant.
• Point 2 livré le 06/11 : cinq promesses About, corrections ESG/Mission et titre Partners; Accelerators et son lien retirés, Assets absent. 12 entrées CMS publiées. Restent : validation visuelle des promesses, traductions, autres textes/chiffres About, catalogue partenaires et textes Contact V2.
• Home : boilerplate retiré et lissage typographique ajusté le 5 novembre; ne pas réintroduire le paragraphe lors de la prochaine synchronisation.

État réconcilié le 4 novembre : /{lang}/about-us/investors, données CMS publiées dans keyrus-ai en quatre langues.

• Hero, citation, calendrier/publications, graphiques, contacts, capital et cotation intégrés. Faire valider les dates et chiffres historiques avant lancement.
• Recette visuelle restent à faire. Le CTA gouvernance conserve la destination publique historique tant que le nouveau parcours est à finaliser. Déploiement non vérifié.

Figma 272:19854 et 272:20193 : sections intégrées avec contenus CMS EN/FR/ES/PT. Regulatory Compliance 272:20558 : hero et trois cartes intégrés, CMS publié en quatre langues.

• Transparency : route /about-us/corporate-governance confirmée. Conseil, profils et audit intégrés; Claude Benmussa remplace le doublon Laetitia de Figma selon les fiches CMS. Mandats et portraits à valider.
• Committed : hero, vision, trois piliers, Fondation, ESG et Awards intégrés. Photo sociale, Fondation et cinq logos exacts Figma dans le CMS. ESG : 4 liens EN/ES/PT, 10 FR; fichiers anglais utilisés pour ES/PT.
• Recette visuelle/clavier et raccordement Investors → Transparency restent ouverts; aucune mise en production affirmée.
• Compliance : hero, transparence, anticorruption et SpeakUp intégrés. Photos exactes Figma; PDF français en FR et anglais en EN/ES/PT. Nom Ethics Line en ES/PT à valider. Aucun nouveau modèle.
• HOM : questions/grille et doublon 2000–2012 à réconcilier. Services : How we help intégré; modalités contractuelles vs géographiques à clarifier.

Updates du 2 novembre précise une destination externe Teamtailor sans page Careers dédiée; l’ancienne question du modèle de page est remplacée par la destination exacte.

• Obtenir l’URL Teamtailor exacte et confirmer son usage pour le menu et les CTA Search & apply! de Home/Contact, dont le lien actuel est signalé en 404.
• Aucun choix de pays par IP requis par principe. Vérifier avec Baptiste si le site Teamtailor gère lui-même pays/langue; ne pas inventer de redirection ni de géolocalisation.

• Careers : choix Teamtailor désormais précisé; obtenir l’URL exacte et vérifier si elle convient au menu et aux CTA Home/Contact. Pas de géolocalisation imposée automatiquement.
• Procurement : titre Sharpen decisions et leviers canoniques visibles dans l’outil; la contribution experte exportée conserve Control Risk & Compliance. Arbitrer la version et la correspondance à importer.
• Preview : Erwan l’avait confirmée fonctionnelle dans la conversation; Updates dit encore to deploy. Réconcilier le statut sans retirer l’acquis. Search locale testée, recette distante non attestée par cet audit.
• Historique migration : premier top 10 = neuf sources retrouvées, puis pilote de dix Blog posts et tests ensuite publiés. Préciser ces étapes plutôt qu’un top 10 initial entièrement migré et toujours en brouillon.
• HOM : grille/copies dans content-web, doublon 2000–2012 encore dans Figma. Modes de collaboration : contenu = Project/Staffing/Team as a service/Managed services; maquette = Project/On-site/Near-shore/Off-shore. Faire préciser la représentation retenue.
• Photos : responsable du choix et échéance à fixer. Transparency : incohérence Figma corrigée dans le rendu avec Claude Benmussa selon le CMS; mandats à valider. Investors : contenus publiés en préproduction, dates/chiffres et documents à valider avant lancement.

À questionner au prochain call, sur demande explicite d’Erwan le 30 octobre 2026.

• Le titre partagé Sharpen Decisions a déjà été corrigé et publié dans keyrus-ai; Energy & Utilities le réutilise. Ce renommage est réalisé, pas en attente de validation.
• Procurement : le bloc 3 source est Control Risk & Compliance. À quel résultat métier doit-il être rattaché dans le nouveau modèle, et faut-il réordonner les blocs ? Valider le mapping avant import; ne pas le renommer mécaniquement Sharpen Decisions.

Catégorie dédiée : propositions d’Erwan du 28 octobre, non arbitrées par Baptiste.

• Voir PO-INS-001 à PO-INS-009 : traductions et slugs, sélection/volume, typologies, livres blancs, tags/pays, SEO, maillage, FAQ/formulaire et validation.

Actualisé le 3 novembre : le plan confirme le gel au 2 novembre, les anciennes propositions sont historiques.

• Portfolio draft 5 et Loop Advise/Build/Operate/Prove gelés; Build/Operate/Prove réutilisent Advise. Les cinq nouveaux écrans et How we help sont disponibles dans Figma.
• Plan : templates/relectures 06/11, import 09–13/11, HubSpot 13/11, live 16/11, go/no-go 20/11, lancement 03/12. Confirmer faisabilité et charge avec Erwan; live ne vaut pas autorisation d’indexer.
• Priorité immédiate : nouvelles maquettes/Search. Décisions du call reçues : HubSpot existant comme socle, Use Cases uniquement, migration ciblée par pays et filtres à adapter; fallback langue/pays ouvert.

• Updates actuelles ↗

• Cadrer 24 capacités sous quatre domaines et deux facettes Challenge/Persona (six personas); vérifier mapping Procurement et capacité du modèle sans hausse d’abonnement.
• Arbitrer les cinq nouvelles industries et le statut contradictoire Public Sector. Challenges, Tax et pages offres proposés après lancement.
• Valider HOM/grille, Technologies/Harness, preuves Prove, chiffres About et awards; rapprochement avec la nomenclature Customer Story encore ouvert.

• Portfolio draft 5 ↗

Plan et content-web relus le 3 novembre.

• Global/local confirmé le 2 novembre : groupe pour l’offre, pays pour leurs entrées. Marketing groupe relit toutes les pages en dernier. Droits CMS, promotion sans copie et formation restent à préciser.
• Updates conserve le relevé du 2 novembre : 23 pages pays envisagées au lancement, 22 owners nommés; Israël manque. Content-web affiche désormais 31 entrées (dont Group) et 29 responsables; cette attribution ne confirme pas le lancement. Six pays exclus pour l’instant : Finlande, Lettonie, Pologne, Rwanda, Suisse, Arabie saoudite. Définir le fallback sans page et les regroupements éventuels; contenu annoncé 20/11.
• Traductions globales vs validation locale, slugs, campagnes et responsabilités de publication restent à arbitrer sans hausse d’abonnement.
• Relevé du 4 novembre : 9/19 experts Reviewed, 5 en cours, 5 non commencées; 0/9 pages site Reviewed et Home en cours. Pays : 29/31 entrées avec responsable, dont Group; Israel sans responsable, rattaché à Europe selon Baptiste; Switzerland sans page prévue. Group et regroupements régionaux à cadrer. Le périmètre de lancement reste à confirmer.

• Content-web ↗

Relevé du 27 octobre 2026 sur content-web.keyrus.pro.

• 59 éléments recensés : 17 pages métier, 9 livrables à produire, 29 pays sans responsable, 4 industries au périmètre à confirmer.
• Écart Retail résolu le 27 octobre : l’export Website team contient les corrections réelles et les titres. La fiche individuelle ne représente pas les réponses consolidées.
• Erwan retient les 12 sujets Reviewed/In progress. Premier lot publié : 109 entrées pour 12 pages, rendu local vérifié; import partiel et code à déployer sur Netlify. Clarifier les titres locaux, les neuf capacités Procurement et les textes absents. Préserver les corrections CMS lors des synchronisations suivantes.

• Source éditoriale ↗

À exécuter uniquement après décision explicite de mise en production. Le générateur sitemap existe, mais sa couverture doit être finalisée avec les pages et contenus réels. La préproduction reste noindex.

• Statut À FAIRE — APRÈS CONTENUS ET ACCORD DE LANCEMENT
• Référence context-ai/03-seo-localization.md

• AVANT BASCULE — Finaliser le sitemap depuis les contenus CMS publiés : couvrir toutes les routes éditoriales et langues réellement disponibles, y compris les détails dynamiques. Vérifier exhaustivité, dédoublonnage et dates lastmod réelles.
• AVANT BASCULE — Ne conserver que les URL finales HTTPS, canoniques, indexables et en HTTP 200. Exclure brouillons, démonstrations, recherches, API, preview, pages de confirmation ou privées, redirections et erreurs.
• AVANT BASCULE — Valider domaine de production, DNS/HTTPS et URL CMS siteUrl ainsi que NEXT_PUBLIC_SITE_URL : le siteUrl CMS est prioritaire dans le code. Vérifier canonical, hreflang réciproques, JSON-LD et liens internes sans localhost ni domaine de préproduction.
• AVANT BASCULE — Recetter métadonnées et contenus, langues JSON-LD, matrice ancienne URL → nouvelle URL et redirections 301/308, absence de chaînes/boucles et vrais 404/410 sans équivalent.
• À L’ACCORD DE LANCEMENT — Activer ENABLE_SEARCH_INDEXING=true uniquement pour l’instance publique finale. Aligner la configuration Netlify effective, notamment le false versionné dans netlify.toml; conserver false sur la préproduction et les previews. Ne pas retirer globalement les protections des autres instances.
• À L’ACCORD DE LANCEMENT — Réexaminer noIndex/noFollow au niveau CMS global et par page; lever uniquement les restrictions des pages validées pour publication. Les pages privées, démos et confirmations restent exclues.
• APRÈS REDÉPLOIEMENT — Vérifier les réponses HTTP et le HTML réel : absence de noindex/nofollow global sur les pages publiques validées, contrôle X-Robots-Tag et balises robots/googlebot. Garder noindex sur les pages exclues; ne pas bloquer leur crawl si le moteur doit lire cette directive.
• APRÈS REDÉPLOIEMENT — Vérifier robots.txt et son lien vers le sitemap final, sitemap XML accessible et non vide, URL et statuts corrects. Vérifier également que la préproduction reste protégée par noindex.
• APRÈS VALIDATION — Vérifier la propriété du domaine dans Google Search Console, soumettre le sitemap, inspecter les pages représentatives et demander leur indexation si nécessaire. Soumission et indexabilité ne garantissent pas une indexation immédiate.
• SUIVI — Surveiller rapports d’indexation, erreurs de sitemap, 404/redirections et canonical retenues; corriger les anomalies après lancement. Si une préproduction est déjà indexée, conserver noindex et envisager les outils de suppression Search Console.

Prise en charge le 27 octobre : plateforme dédiée activée pour les 58 modèles Keyrus AI. Code étendu à tous les templates actuels; déploiement et recette distante restent à faire.

• Routes Page, Insight, événements, vidéos et Thank You, Customer Stories et Use Cases; sections et taxonomies ouvertes via leurs pages parentes, avec choix si plusieurs destinations.
• Contenu non rattaché : message explicite. Les composants globaux se prévisualisent sur l’accueil. Brouillons et variantes restent soumis aux champs requis par les templates.
• Règle demandée par Erwan : tout nouveau template ou content type doit être accompagné de sa preview, de sa configuration CMS et des vérifications brouillon/langue avant clôture.
• Configuration limitée à la plateforme Keyrus AI créée par Erwan; deux previews historiques vérifiées inchangées. Aucun modèle master ajouté; la limite documentaire précédemment envisagée ne bloque pas cette API.
• 23 tests ciblés réussis. Déployer et recetter après résolution du blocage Netlify sur le token Preview. Aucun déploiement ni test distant de tous les modèles affirmé; Live Preview automatique non intégré.

Hypothèse d’Erwan du 26 octobre : keyrus-ai pour le futur keyrus.com, master conservé pour les autres sites historiques. Organisation à décider.

• Inventorier les environnements réellement utilisés par chaque site; définir où les contributeurs doivent créer, prévisualiser et publier selon la destination.
• Clarifier accès, responsabilités et contenus partagés pour éviter les erreurs entre environnements; aucune synchronisation automatique décidée.
• Contenus mutualisés : étudier une source éditoriale unique avec adaptateur de lecture ou synchronisation vers le nouveau modèle. Définir aussi corrections, langues, destinations et dépublications; éviter deux copies éditées indépendamment. Aucun choix technique validé.
• Préparer configuration des déploiements, webhooks, gel ou reprise des mises à jour et retour arrière. Préserver les sites historiques; aucune bascule ni écriture dans master autorisée ici.

Pilote recentré le 28 octobre sur 10 Blog post en brouillon, avec leurs SEO. Trois livres blancs du premier lot restent hors périmètre et en attente. Relecture et publication réservées à Erwan.

• Typologies vérifiées : premier lot = 6 Blog post et 3 White Paper. Lot révisé = 10 Blog post (9 ES, 1 FR), 4 ajouts sans publication; livres blancs conservés à part en brouillon. Image supermarket sans fichier dans demand forecast à restaurer. Corriger le mapping par typologie avant toute extension; rapport du pilote actualisé.
• Export Search Console fourni : 1 000 URL, dont 615 Insights, période du 26/06/2025 au 25/10/2026. Top 10 par clics puis impressions; 9 correspondances exactes dans keyrus-ai, article solution-ia-appels-offres-marche-public absent. Aucun accès à master effectué.
• 9 kaiInsight et 9 kaiSeoMetadata créés et relus en brouillon, 36 assets existants réutilisés, sources inchangées. Aucune publication. Relecture CMS/preview par Erwan : SEO raccourci aux limites, taxonomies non mappées et fallback en-US contenant le texte source à vérifier. Rapport et liens : docs/cms-data-strategy/09-keyrus-ai-insight-migration-pilot.md.
• Mapper champs, rich text, médias, auteurs, taxonomies, dates, SEO, slugs et relations; faire arbitrer les champs sans équivalent et données manquantes.
• Préparer un import API avec sauvegarde, simulation, dédoublonnage, correspondance des identifiants et relance sans duplication. Tester un échantillon en brouillon avant le lot validé.
• Recetter le contenu et le rendu, définir la publication, traiter les mises à jour pendant la migration et établir les redirections depuis les anciennes URL. Charge et calendrier à estimer.
• Établir ancienne URL complète → nouvelle URL finale. Le retrait du pays peut créer des collisions : arbitrer variantes et traductions avant toute fusion. Définir aussi le sort des contenus non repris.
• Activer au lancement les redirections permanentes Netlify/serveur vers des pages pertinentes en HTTP 200, sans boucle ni chaîne. Les redirections ne sont pas gérées par le sitemap; celui-ci doit lister les nouvelles URL canoniques indexables.
• Mettre à jour liens internes, canonical et hreflang; contrôler les anciennes URL et surveiller 404, indexation et trafic Search Console après bascule. Préproduction et previews restent noindex.
• Conserver les identifiants source/cible et définir la source éditoriale de référence pour les publications partagées. Aucun nettoyage CMS pour le moment; préserver contenus et modèles historiques.

Reporté par Erwan le 27 octobre : garder les anciens content types et contenus dans keyrus-ai. Aucun nettoyage maintenant.

• Auditer les entrées, assets, références et consommateurs avant de proposer un retrait des modèles historiques présents dans keyrus-ai.
• Effectuer les reprises nécessaires avant de retirer les sources ou dépendances; conserver les environnements utiles aux anciens sites.
• Aucune suppression ni fusion autorisée : inventaire, sauvegarde et validation ciblée requis. Stratégie liée aux décisions de production et de migration.

Proposition à valider avec Baptiste : groupes repliables créés via API sur Page et Insight dans keyrus-ai, le 26 octobre 2026.

• Page : Informations générales, Composition de la page, Classification et ciblage, SEO et indexation (15 champs).
• Insight : Contenu, Auteur et publication, Présentation des cartes, Classification, Sections complémentaires, SEO (25 champs).
• Liens des exemples fournis par Erwan le 26 octobre : voir ci-dessous. Faire valider libellés, ordre, répartition et facilité de saisie; aperçu du site en preview à ajouter une fois le raccordement terminé.
• Convention commune documentée dans context-ai/02-cms-and-content-model.md : mêmes responsabilités, mêmes libellés et identifiants; variantes explicites selon les champs (SEO / SEO et indexation, Classification / Classification et ciblage). Réutiliser uniquement les groupes utiles, sans créer de content types supplémentaires.
• Les onglets ne sont pas affichés par l’éditeur web : conserver les groupes repliables. Aucun contenu ni définition de champ modifié.

• Page · Contact — groupes CMS ↗
• Insight · Article de démonstration — groupes CMS ↗

Décision d’Erwan du 26 octobre 2026 : aucune hausse d’abonnement pour augmenter le nombre de content types.

• 150 modèles observés, dont 58 kai* et 92 historiques; plafond contractuel exact encore à confirmer.
• Réutiliser et composer les modèles existants. Si nécessaire, proposer une rationalisation après audit des usages, sans suppression ni fusion automatique.
• Contrainte à respecter pendant la revue CMS; aucune augmentation de capacité payante à proposer.

Orientation d’Erwan du 26 octobre 2026 : une recherche transverse sur les contenus CMS avec une expérience dynamique; solution technique non arrêtée.

• Statut MAQUETTE INTÉGRÉE / RECETTE FINALE À FAIRE
• Chantier Search — interface, données et moteur

• Définir l’interface, l’accès à la recherche, les résultats, suggestions éventuelles, filtres, pagination et états vide, chargement et erreur; préciser ce que signifie une recherche dynamique.
• Confirmer le périmètre public indexable, les champs recherchés, langues et exclusions. L’objectif de tout rechercher dans le CMS ne signifie pas exposer les brouillons ou contenus internes.
• Choisir ensuite entre recherche native CMS, index externe ou moteur dédié; définir pertinence, mise à jour après publication, performance et accessibilité clavier.
• MiniSearch retenu, V1 locale du 30 octobre adaptée à Figma le 3 novembre : cartes avec photos CMS, facettes et compteurs, Show more par six, accès Tous/Pages. TypeScript et 16 tests réussis. Première observation desktop/API; clics et mobile à recetter après reprise du serveur local. Déploiement et actualisation Netlify à vérifier. Aucune recherche sémantique promise.

Question à transmettre à Baptiste : devra-t-on adapter le socle Keyrus AI pour refondre plusieurs sites du groupe avec ce branding, notamment Management et Fondation ?

• Statut Baptiste À CLARIFIER
• Relevé le 26 octobre 2026
• Lien TECH-ARCH-001 — réflexion technique différée

• Confirmer les sites concernés, leur ordre de priorité, le calendrier, le budget et le responsable de la décision.
• Préciser ce qui sera identique ou variable : branding, templates, navigation, langues, fonctionnalités et autonomie éditoriale.
• Confirmer si les modèles et contenus CMS seront partagés ou distincts, avec quelles permissions et règles de publication.
• Erwan souhaite approfondir les pistes de configuration par site et d’accès CMS mutualisé; ce sont des pistes, pas une architecture validée ni un engagement de livraison.
• Maintenir le périmètre actuel Keyrus AI pour le 3 décembre 2026. Planifier une éventuelle mise en œuvre multisite ensuite, après arbitrage.

Décision d’Erwan du 26 octobre 2026 : conserver le fonctionnement actuel pour Keyrus AI et reporter la structuration destinée aux autres sites après l’échéance du 3 décembre 2026.

• Statut DIFFÉRÉ — APRÈS ÉCHÉANCE
• Périmètre Keyrus AI uniquement pour la livraison actuelle

• Maintenir les adaptateurs CMS dans keyrus-ai et les composants visuels réutilisables dans keyrus-ui; ce principe est adapté au besoin actuel, sans affirmer que chaque composant est déjà optimal.
• Lors d’une future refonte de Keyrus Management, Fondation ou d’autres sites, réutiliser la bibliothèque et conserver les compositions spécifiques dans chaque application.
• Étudier un package commun de requêtes, types et adaptateurs seulement si les modèles CMS sont réellement partagés; utiliser le même CMS ne suffit pas à justifier cette mutualisation.
• Extraire les compositions réutilisables comme ContactPageContent en templates partagés recevant des propriétés simples; laisser l’adaptation Contentful dans un adaptateur distinct.
• Créer une configuration par site : identité, domaine, langues, navigation, thème et sélection des contenus. Définir explicitement la séparation des contenus et les paramètres propres à chaque site.
• Déplacer les composants visuels réutilisables encore locaux vers keyrus-ui; remplacer les textes, styles, identifiants CMS ou destinations spécifiques par des paramètres lorsque nécessaire.
• Partager les outils SEO, JSON-LD, localisation et résolution des liens, alimentés par la configuration du site.
• Conserver les routes page.tsx, compositions particulières et déploiements dans chaque application; éviter un template unique imposé à tous les sites.
• Parcours cible envisagé : page du site → requêtes CMS → adaptateur → template partagé → composants UI. Les responsabilités peuvent être partagées ou spécifiques selon les besoins réels.
• Harmoniser les adaptateurs sans valeur ajoutée et les frontières de responsabilités lors de cette future revue.
• Aucun refactoring multi-site engagé maintenant; ce point technique ne bloque pas la livraison actuelle.

Piste proposée par Erwan lors de la revue de code du 26 octobre 2026 : évaluer les redirections géographiques Netlify pour remplacer le besoin de détection côté application.

• Statut À VALIDER
• Relevé le 26 octobre 2026
• Fichier packages/keyrus-ai/netlify/edge-functions/geolocation.js

• Le fichier expose le pays estimé via Netlify sur /api/geolocation; il ne dépose aucun cookie. Son appel identifié sert actuellement à LocalizationDebug.
• Définir si une redirection par pays est réellement nécessaire, ses destinations et le comportement quand le pays est inconnu.
• Distinguer pays et langue : conserver la priorité au choix explicite de langue de l’utilisateur et éviter les boucles de redirection.
• Vérifier la configuration Netlify, son interaction avec le middleware et les conséquences SEO avant remplacement.
• Faire valider la finalité, la base légale et l’information de confidentialité du traitement Geo/IP; préciser la nécessité éventuelle de consentement selon l’usage. Aucun cookie dans ce fichier ne signifie pas absence de traitement de données.
• Après arbitrage et recette, supprimer la fonction et son appel de diagnostic si devenus inutiles. Aucune suppression ou redirection n’est effectuée à ce stade.

Template Figma 1:16517 intégré avec un logo fictif et des résultats de démonstration. Page en noindex en attendant validation.

• Statut OUVERT
• Constaté le 16 octobre 2026
• CMS kai-story-template-demo

• Fournir le logo client réel et confirmer son autorisation de publication.
• Use Case 1:16903 intégré sans logo, avec trois résultats : confirmer si ces chiffres sont constatés ou attendus; variante CMS explicite mais stratégie éditoriale encore ouverte.
• Valider les résultats 40 %, 15+ et 90 %, leur source, leur périmètre et l’accord du client.
• Fournir textes, citations, traductions, date et réponses FAQ définitifs; confirmer les contenus associés et leurs destinations.
• Arbitrer tags, structure CMS et distinction Customer Story nommée / Use Case anonyme; parcours suivi dans PO-NAV-003.
• Définir destination et consentement du formulaire; aucun envoi actif.

Figma 1:14940 intégré avec une démonstration CMS en noindex. Structure provisoire à valider avec Baptiste.

• Statut OUVERT
• Constaté le 16 octobre 2026
• CMS kai-article-template-demo

• Valider textes, citations, tableau, réponses FAQ, traductions et date de publication.
• Confirmer le profil LinkedIn auteur : le lien provisoire ouvre une recherche nominative.
• Définir le rattachement des tags à la taxonomie et la sélection des contenus associés.
• Confirmer les destinations des suggestions et du CTA Browse all, actuellement dirigés vers le listing Insights.
• Définir destination du formulaire, consentement et traitement des données; aucun envoi actif.

La sixième carte Figma 1:8674 répète « 2000-2012 / Digital intelligence » après « 2022 – 2025 / Augmented intelligence » dans la section 1:8619.

• Statut OUVERT
• Constaté le 16 octobre 2026
• CMS kai-hom-history · six cartes éditables

• Les six cartes sont conservées dans l’ordre Figma en attendant validation.
• Confirmer si la dernière carte doit être remplacée, supprimée ou conservée.
• Fournir les dates, le titre et le texte définitifs; aucun contenu historique supplémentaire n’a été inventé.

La frame Figma 1:3991 décrit une page pays France avec le breadcrumb Locations → France, des bureaux, événements et entités locales. Elle ne correspond pas au sélecteur de langue.

• Statut OUVERT
• Constaté le 8 octobre 2026
• Maquette Location Page · Figma 1:3991
• Menu Figma aucun lien Locations / Offices
• Menu front aucun lien Locations / Offices
• Route /{lang}/locations/france · hero, clients, équipe et Events intégrés
• Risque page accessible par URL mais orpheline

• Option recommandée à examiner : exposer Locations dans le sous-menu About us, puis dans Who we are si la navigation cible à trois entrées est retenue.
• Options complémentaires : lien dans le footer ou depuis la carte mondiale de la homepage.
• La détection automatique du pays peut personnaliser des contenus secondaires, mais elle ne remplace pas un accès navigable aux pages pays. Aucun sélecteur manuel de pays n’est prévu à ce stade.
• Aucune de ces options n’est actée; l’intégration de la page peut avancer sans modifier le menu tant que ce point reste ouvert.

Le plan fournit une direction de menu et des familles de templates, mais précise que le sitemap exhaustif repose sur des tâches ClickUp invisibles dans l’export. On ne peut donc pas affirmer que toutes les pages et sous-pages sont définies.

• Statut OUVERT
• Source plan archivé · section Design / sitemap
• Disponible menu à 3 entrées + inventaire de templates
• Manquant arbre complet, profondeur, URL, 2 consolidations
• Attention certaines sections ne sont pas des pages autonomes

• Demander le sitemap ClickUp lisible ou une matrice validée menu → parent → sous-page/détail → URL → template.
• Faire préciser les deux blocs à consolider et les sections qui ne deviendront pas des pages.
• Vérifier dans cette matrice l’accès aux pages About Us, HOM, pays, technologies et aux contenus éditoriaux.

Les listings Customer Stories (1:6219), Insights (1:6839), Videos (1:8685) et Events (1:8989) sont intégrés provisoirement. Leur accès depuis le futur menu principal et les détails des cartes restent à valider.

• Statut OUVERT
• Proposition menu Insights → index Figma Insights (1:6839)
• Front /{lang}/customer-stories et /{lang}/resources/{insights,videos,events} ; détails absents
• Source plan archivé + frames Figma 1:6219 / 1:6839 / 1:8685
• Menu Use cases / Insights / Events / Videos
• Figma Insights > Customer Stories ; Resources > Videos
• Figma listing Insights → Resources ; Events → Events
• Attention 2e frame « Insights » (1:7141) = page HOM™
• Question une page Resources filtrée ou plusieurs listings ?

• Confirmer avec Baptiste la direction proposée : l’entrée Insights ouvre le listing Figma 1:6839.
• Confirmer si les quatre accès mènent à des listings distincts ou à des vues filtrées d’un index commun.
• Confirmer si Customer Stories et Use cases partagent durablement ce listing et comment accéder aux stories nommées.
• Valider les parents des fils d’Ariane, l’URL canonique du listing, les destinations des cartes et le libellé Videos, Demos ou Media.

La frame Partners (Figma 1:9339) affiche Technologies et réunit les partenaires technologiques et les accélérateurs. Le plan archivé place Technologies sous What we do, avec deux cartes, mais ne précise pas si elles ouvrent deux pages ou deux sections d’une même page.

• Statut OUVERT
• Figma Partners · 1:9339 ; hero Technologies
• Prototype /{lang}/technologies, entrée actuelle du menu reliée
• Plan What we do → Technologies → 2 cartes
• Cartes Technology partners / Keyrus accelerators
• À trancher libellé, URL, destinations, classement

• Valider le libellé public Technologies ou Partners et sa place dans le futur menu What we do.
• Décider si les deux cartes mènent à deux sections de la page Figma ou à deux pages distinctes; fournir les URL et les liens internes correspondants.
• Confirmer le regroupement des partenaires par capability comme dans Figma, ou par couche HOM comme questionné dans le plan.
• Valider les contenus définitifs des trois accélérateurs et les destinations de leurs boutons Learn more ; le prototype reprend les textes Figma et garde les CTA sans destination en attendant cette décision.

Customer Stories utilise provisoirement six entrées kaiUseCase; Insights neuf kaiInsight, Videos neuf kaiVideo et Events huit kaiEvent de démonstration. Les contenus finaux, les droits sur les logos et les champs de filtre restent à trancher.

• Statut OUVERT
• Figma Article / Customer Story / Use Case / Event / Video
• CMS actuel kaiInsight / kaiUseCase / kaiEvent / kaiVideo
• Listings Customer Stories, Insights, Videos et Events intégrés provisoirement
• Filtres aucune taxonomie renseignée ; Country sans relation CMS
• Plan Story et Use Case partagent un template visuel
• Variante logo client seulement avec autorisation

• Confirmer les types éditoriaux publiables : Article/Insight et Customer Story nommée/Use Case anonyme.
• Décider si Story et Use Case partagent aussi un modèle CMS, et quels champs ou validations conditionnent l’autorisation du logo client.
• Préciser quels types alimentent chaque listing et ses filtres, puis les URL et breadcrumbs de chaque détail.
• Fournir les contenus définitifs et les taxonomies des cartes de démonstration des trois listings; statuer sur le ciblage Country avant de l’activer.

Le listing Events Figma 1:8989 est intégré avec huit événements de démonstration. La maquette donne des jours et mois, sans années ni destination d’inscription; les années techniques servent uniquement à rendre le filtre Upcoming testable.

• Statut OUVERT — page noindex
• Source Events · Figma 1:8989
• CMS 8 kaiEvent, dates et lieux de démonstration
• Filtres Search / Upcoming / Type actifs; Country différé
• Parcours détail démo intégré; inscription non connectée (PO-EVT-002)

• Fournir les vrais événements, leurs années, heures, fuseaux, lieux et modalités virtuelles.
• Définir les statuts à venir/passé, le comportement du filtre Upcoming et la durée de conservation des archives.
• Valider les destinations des cartes, les pages détail et les formulaires ou URL d’inscription.
• Définir une relation pays événement fiable avant d’activer By country; lever noindex après remplacement des données de démonstration.

Le template Event Registration Figma 1:15910 est intégré et alimenté par Contentful. La démonstration est noindex; le formulaire ne transmet aucune donnée.

• Statut OUVERT — 19 octobre 2026
• Route /en/resources/events/event-registration-demo
• CMS kaiEvent + sections + kaiPerson + kaiFormReference
• Date 2027-01-01 technique, non validée

• Valider le prestataire (HubSpot ou autre), la destination des données et les états de confirmation et erreur.
• Fournir date, heure, fuseau, lieu, URL et carte réels. Le lien du lieu reste désactivé et le JSON-LD Event absent.
• Valider champs obligatoires, liste des pays, consentement et textes légaux : Submit dans le texte, Register sur le bouton Figma.
• Fournir les vrais intervenants et profils LinkedIn; remplacer les bénéfices provisoires et arbitrer les sessions répétées et la FAQ générique.

La maquette 1:17282 ressemble à un article lié à un événement, sans formulaire ni programme. Elle est intégrée provisoirement comme variante insight de kaiEvent, distincte de registration.

• Statut OUVERT — 19 octobre 2026
• Route /en/resources/events/event-insight-demo
• CMS kaiEvent.templateVariant = insight
• Contenu démonstration noindex, date non validée

• Confirmer si cette page est un compte rendu après événement, une présentation avant événement ou une catégorie éditoriale indépendante.
• Décider si une fiche passe de Registration à Insight sur la même URL, ou si deux fiches distinctes doivent être reliées.
• Valider sa présence dans Events et/ou Insights, les filtres et le statut des événements passés.
• Fournir dates, lieu et contenu réels; confirmer les recommandations Use case et les destinations Browse all de la maquette.

Contact Us (Figma 1:10110) est intégré avec un formulaire local sans envoi, la carte interactive mondiale de la homepage, les huit bureaux France existants, Careers et une FAQ de démonstration.

• Statut OUVERT — 19 octobre 2026
• Route /en/contact
• CMS kaiPage contact + sections existantes
• Publication noindex en attendant validation

• Configurer le prestataire de formulaire, la destination CRM, le routage pays/sujet, les confirmations et la protection anti-spam.
• Valider les champs obligatoires, la liste des pays et les textes de consentement et confidentialité. Aucun envoi ni consentement marketing précoché actuellement.
• Confirmer le périmètre : carte mondiale mais bureaux français dans Figma. Doit-on afficher les bureaux mondiaux, filtrer par pays ou relier la carte aux fiches ?
• Valider les adresses historiques réutilisées et remplacer les six questions/réponses FAQ de démonstration.
• Confirmer si Book a consultation renvoie au formulaire Contact ou à un outil de réservation. Le lien actuel remonte au formulaire.

Le template Insight – Video (Figma 1:17650) est intégré comme détail kaiVideo, avec hero, résultats, formulaire/résumé et intervenants. La maquette ne fournit pas la vidéo Meta : le média CMS existant Humanizing the future est utilisé provisoirement à la demande utilisateur.

• Statut OUVERT — 19 octobre 2026
• Route /en/resources/videos/vendor-workforce-planning-demo
• Publication démonstration noindex

• La maquette Thank You (1:15318) précise un écran de lecture après inscription, intégré sous /resources/videos/[slug]/thank-you sur la même fiche CMS. Confirmer redirection, accès direct, persistance de l’accès et protection éventuelle côté serveur; noindex ne protège pas la vidéo.
• Fournir le fichier vidéo ou son URL de diffusion, le sous-titrage, la transcription, la durée et la date de publication. Choix de stockage à relier à PO-VID-001.
• Confirmer si la vidéo est libre, accessible après inscription, ou si le formulaire répond à un autre objectif. Le CTA actuel mène au formulaire; aucun envoi ni déblocage simulé.
• Définir le prestataire formulaire/CRM, les consentements et le parcours de confirmation.
• Valider le libellé Partners du hero, les chiffres et le texte Meta; les trois portraits du hero diffèrent des portraits répétés de la section Speakers.
• Fournir noms, fonctions et profils LinkedIn réels; la démonstration reprend le libellé Figma Name Surname et le lien institutionnel Keyrus.

Le template Videos (Figma 1:8685) suggère que la vidéo pourrait prendre une place plus importante dans la stratégie du site. C’est une hypothèse à discuter avec Baptiste : la fréquence de publication, le volume et la durée des vidéos ne sont pas encore connus.

• Statut OUVERT — hypothèse éditoriale, pas décision
• Source maquette Videos · Figma 1:8685
• Formats webinars, démos, interviews, highlights
• Inconnu cadence, durée, qualité et volume à publier
• Impact stockage, transcodage, diffusion et coûts
• Migration inclure les médias dans le comparatif CMS

• Demander à Baptiste si la vidéo devient un axe éditorial prioritaire et à quelle fréquence des vidéos seraient publiées.
• Estimer ensuite les volumes de stockage et de diffusion à partir de la durée, de la résolution et des formats cibles.
• Définir un processus d’optimisation : encodage, variantes adaptées aux écrans, vignettes, sous-titres, CDN et archivage.
• Intégrer ces besoins au choix entre conserver Contentful, migrer vers un autre CMS ou utiliser une plateforme vidéo spécialisée liée au CMS.

Le libellé Locations → France suggère un niveau parent, mais ne prouve pas qu’une page index est prévue. Ni la maquette inventoriée ni le plan exporté ne décrivent cet écran; la homepage possède déjà une carte mondiale interactive.

• Statut OUVERT
• Constaté le 8 octobre 2026
• Figma page pays France · pas d’index identifié
• Plan page France détaillée · pas d’index décrit
• Front /{lang}/locations/[slug] · pas de /{lang}/locations
• Risque parcours pays/bureaux incomplet ou carte dupliquée

• Demander si un index des pays est nécessaire, ou si la carte de la homepage, About Us et des liens directs suffisent.
• Si un index est souhaité, demander sa maquette, sa place dans la navigation et ses règles de tri/filtrage.
• Ne pas compter ce template comme définitivement requis avant l’arbitrage.

Le plan propose des pages pays riches dans le site global, mais ne spécifie ni tous les pays concernés ni leur calendrier. France est le seul exemple détaillé et son contenu local est annoncé comme très exigeant à maintenir.

• Statut OUVERT
• Source plan.keyrus.pro · Design / Internationalisation
• Exemple France · Figma 1:3991
• Périmètre pays de lancement non défini
• CMS modèle réutilisable, instances pays à confirmer
• Risque charge de contenu et de traduction indéterminée

• Valider la liste des pays disposant d’une page dédiée au lancement, puis les vagues suivantes.
• Préciser les contenus obligatoires, les responsables éditoriaux et le traitement d’un pays sans page dédiée.
• Garder les URLs pays stables et indépendantes de la langue et de la géolocalisation automatique.

Figma montre des icônes LinkedIn et e-mail sur les onze cartes de la page France, mais ne fournit aucune destination individuelle vérifiée. Les portraits, noms et fonctions sont dans le CMS; les liens restent masqués.

• Statut OUVERT
• Maquette Section Team · Figma 1:4335
• CMS kaiPerson.linkedinUrl / kaiPerson.email disponibles mais vides
• Front liens conditionnels, aucune URL fictive

• Fournir les URL LinkedIn et les adresses publiques validées pour chaque dirigeant, ou confirmer la suppression des icônes.
• Vérifier les noms, fonctions et portraits avant publication finale, car ces données locales sont sensibles aux changements organisationnels.

La maquette Events de la page France montre trois photos et des textes latins de démonstration. Le bouton indique Browse all insights, sans destination prête sur le nouveau site. Les aperçus sont structurés dans le CMS mais restent non cliquables.

• Statut OUVERT
• Maquette Section Events · Figma 1:4286
• CMS kaiSectionCardGrid + 3 aperçus kaiInsight marqués placeholders
• Front section visible, cartes et CTA sans lien actif
• Question Events ou Insights pour le CTA ?

• Fournir les vrais contenus France, leurs dates si ce sont des événements, leurs images et leurs destinations.
• Confirmer si le CTA doit ouvrir un listing Events, Insights ou un autre parcours localisé.
• Remplacer les textes latins et activer les liens seulement après publication des routes correspondantes.

La section Our brands in France de Figma présente cinq entités et le site Keyrus actuel fournit leurs liens. Une publication financière Keyrus évoque cependant la cession de Xiomega : la composition du groupe doit être confirmée avant lancement.

• Statut OUVERT
• Maquette Section Our brands · Figma 1:4671
• CMS 5 kaiNavigationItem + kaiSectionCardGrid, publiés dans keyrus-ai
• Front 5 cartes et liens externes visibles sur /{lang}/locations/france
• À valider marques actuelles, textes et destinations officielles

• Faire confirmer la liste des cinq marques par Baptiste et le corporate, en particulier le statut de Xiomega.
• Vérifier les descriptions et URL avant mise en production; la maquette et le site existant peuvent être datés.

Les huit bureaux visibles dans Figma ne concordent pas entièrement avec l’annuaire historique Contentful. Le prototype suit la maquette; chaque nouvelle fiche conserve un lien vers l’enregistrement source pour faciliter la vérification.

• Statut OUVERT
• Maquette Section Locations · Figma 1:4154
• CMS 8 kaiOffice + sourceLocation vers les entrées location historiques
• Écart Nantes : 2 Rue de l’Allier (Figma) / 9 Rue La Noue Bras de Fer (ancien CMS)
• À valider adresses, téléphones, noms et photos actuels

• Faire confirmer toutes les coordonnées par les responsables locaux avant publication de production.
• Mettre à jour les fiches kaiOffice validées sans écraser automatiquement l’annuaire historique.

La maquette montre cinq champs personnels et Submit, mais ne définit pas l’intégration ni les mentions de confidentialité. Le bloc est intégré visuellement et piloté par le CMS; aucune donnée n’est envoyée pour l’instant.

• Statut OUVERT
• Maquette CTA · Figma 1:4161
• CMS kaiSectionCta + kaiFormReference + 5 champs localisables
• Front bouton intercepté, message CMS, aucune soumission réseau
• À valider provider, identifiant, confidentialité, succès et erreurs

• Fournir l’identifiant de formulaire HubSpot ou un endpoint sécurisé validé, ainsi que la finalité de la collecte.
• Valider mentions de confidentialité/consentement, conservation et états succès/erreur avant d’activer Submit.
• Tester le parcours de bout en bout sans transmettre les données dans une URL GET.

Des URL lisibles dans la langue du visiteur seraient cohérentes avec les quatre langues mondiales, sans constituer à elles seules un levier de trafic ou de visibilité GEO garanti. Le choix doit précéder la multiplication des pages et la migration des anciennes URL.

• Statut OUVERT
• Exemple /en/locations/france ↔ /es/ubicaciones/francia
• À décider slug éditorial seul ou segments + slug traduits
• CMS actuel kaiPage.slug commun aux langues
• Technique mapping des routes, canonical, hreflang, sitemap
• Migration redirections permanentes URL par URL
• Contenu ne pas présenter un fallback anglais comme une traduction

• Google recommande des mots descriptifs dans la langue du public, mais ne garantit aucun gain de classement lié au seul changement d’URL.
• Conserver /en, /fr, /es et /pt comme langues mondiales : traduire un slug ne crée pas automatiquement une variante pays comme /es-es.
• Comparer le bénéfice de clarté pour chaque famille avec le coût CMS, la validation éditoriale et le risque de migration des URL déjà performantes.
• Si la traduction est retenue, définir des liens hreflang vers les vraies traductions, des canonicals cohérents et un plan de redirection 1:1 depuis les anciennes URL.
• Référence de suivi : KEYRUS_AI_SEO_URL_MIGRATION.md, décision « Slugs traduits ou communs » encore ouverte.

Dans Who we help du template Services, la carte Data & technology leaders reprend un texte destiné aux équipes Finance. Le prototype suit exactement la maquette, mais ce doublon ne doit pas être validé pour la production.

• Statut OUVERT
• Constaté le 9 octobre 2026
• Figma Services · Who we help · 1:5918
• CMS kai-service-advise-audience-data
• À fournir description validée pour Data & technology leaders

• Demander au Baptiste le texte correct avant de publier définitivement la page Advise.
• La description actuelle reste modifiable directement dans Contentful keyrus-ai.

La section Case studies est intégrée avec trois exemples et des textes latins de la maquette. Les destinations Use cases ne sont pas encore construites : les cartes et le bouton restent visibles, sans liens actifs.

• Statut OUVERT
• Constaté le 12 octobre 2026
• Figma Services · Case studies · 1:5845
• CMS Pladis, Typeform et VivaGym réutilisés dans keyrus-ai
• Routes /{lang}/use-cases et détails : 404
• Front liens désactivés sur la section Advise

• Confirmer que ces trois clients sont bien les preuves pertinentes pour Advise et fournir des titres/résumés réels.
• Valider la destination du bouton et des cartes, puis activer leurs liens après intégration et recette des pages correspondantes.

La FAQ et son CTA sont intégrés, mais Figma ne fournit qu’une réponse sur quatre. Le formulaire et le lien Contact restent inactifs faute de destination et de cadre de collecte validés.

• Statut OUVERT
• Constaté le 12 octobre 2026
• Figma Services · FAQ · 1:5661
• CMS kai-service-advise-faq et formulaire associé
• Front aucune donnée transmise; lien Contact inactif

• Faire valider les trois réponses manquantes; elles restent exclues du JSON-LD FAQ tant qu’elles sont provisoires.
• Fournir une route Contact, un formulaire connecté, les mentions de confidentialité et les états succès/erreur avant activation.

• Confirmer 44 ou 45 partenaires et leurs pages au lancement.
• Valider le Loop et la règle Insights langue/pays.
• Vérifier la borne 05/05, les volumes et le chevauchement des lots de migration.

• Quels partenaires ont une page au lancement, et quelle liste finale entre 44 et 45 ?
• Valider la proposition web Loop/Harness et fournir les textes Build/Operate/Prove.
• Finaliser la sélection Use Cases, la règle langue/pays et l’URL Teamtailor.

• Plan actuel ↗ — Périmètre V2, jalons et contenus
• Contenus ↗ — Suivi éditorial actuel
• Template partenaire ↗ — Copie Figma inspectée via MCP

• Validation des textes historiques pour le nouveau site et complétude des traductions.
• Confirmer les documents régionaux à conserver au lancement.

• Quels contenus retenir comme Worldwide ?
• Quel fallback lorsque la langue choisie ne correspond pas aux contenus du pays détecté ?

• Liste désignée par Baptiste ↗ — Sélection à rapprocher des entrées CMS et des statuts du tableau

• Gel confirmé dans le plan le 2 novembre; confirmer la charge et les dates intermédiaires avec le développement.
• Arbitrer périmètre lancement : pays, vague 2, Challenges/Tax/offres, formulaires/recherche, reprise Keyplays.
• Valider global/local, owners pays, gouvernance linguistique, slugs traduits/communs et deuxième contrôle éditorial.

• Plan actuel ↗ — Overview et calendrier proposé.
• Portfolio draft 5 ↗ — Loop, capacités et évolutions du catalogue.
• Contenus et gouvernance ↗ — Responsabilités, pays et circuit éditorial.
• Design ↗ — Écrans historiques, nouveau Loop à concevoir.

• PO-CONTENT-NAMING-001 : abandonne-t-on définitivement Customer Story ? Quel libellé le remplace ?
• Conserve-t-on une distinction entre cas client nommé et use case anonyme dans les contenus et le CMS ?
• Quels contenus de content-web.keyrus.pro sont validés, pour quelles pages et langues ?
• Quels composants bénéficieront en priorité des micro-animations ?

• Contenus du nouveau site ↗ — Source éditoriale désignée pour la future intégration des contenus.
• transitions.dev ↗ — Transitions prêtes à intégrer; plus de 43 selon la référence communiquée.
• morphicons — Icônes Lucide, Heroicons et Tabler. URL précise à compléter.
• itshover — Interactions au survol. URL précise à compléter.
• libraries.dev ↗ — Bibliothèques d’interface.
• benco.dev ↗ — Interactions au survol, clic, glissement et sélection.
• beautifului.dev ↗ — Composants d’interface, notamment pour des produits IA.

• PO-SVC-LOOP-001 : remplacement définitif du modèle actuel ? Noms, livrables et cinq rôles ?
• PO-SVC-LOOP-002 : une page ou plusieurs, routes et nouvelles maquettes ? Nearshoring transversal ou page dédiée ?
• PO-NAV-FEATURED-001 : responsable éditorial, sélection par langue/pays, droits logo et comportement sans sélection ?
• Conserver les arbitrages existants : accès About Us, Investors/newsroom et destinations des deux cartes Technologies.

• Le domaine final reste-t-il exactement keyrus.com ?
• Quelles langues et quels marchés seront publiés au lancement ?
• Quelles URLs performantes doivent absolument conserver leur chemin actuel ?

• Les slugs doivent-ils être traduits ?
• Qui valide chaque variante locale ?
• Quel hébergement et quel CDN porteront la géolocalisation en production ?
• Quand autorise-t-on l’ajout des champs pays/marché dans Contentful ?

• Valider la pertinence sur le corpus public et les contenus migrés.
• Faut-il une recherche sémantique dès le lancement ?
• Quels filtres sont réellement utiles ?

• Pillar couvre-t-il Industries et Business Functions ?
• HOM mérite-t-il une narration dédiée ou peut-il réutiliser Standard/About Page ?
• Les pages légales ont-elles des besoins au-delà d’un rendu rich text standard ?
• Un index Locations distinct de la carte mondiale est-il nécessaire ?

• What we do ou How we help ?
• Technologies ou Partners ?
• Use cases ou Customer Stories ?

• Contentful est-il conservé après la période actuelle ?
• Quels contenus historiques doivent réellement migrer ?
• Quels champs nécessitent une localisation ?

• Quelle est la date de lancement validée ?
• Qui signe le go/no-go ?
• Combien de cycles de recette sont prévus ?

• Le workshop Shift a-t-il définitivement validé le menu à trois entrées ?
• Qui ferme les six décisions encore ouvertes et à quelle date ?
• Le calendrier du 3 décembre doit-il être maintenu ou rebaseliné ?

• Peux-tu nous transmettre le sitemap ClickUp complet avec parents, sous-pages, URL et les deux consolidations en suspens ?
• Valide-t-on que l’entrée principale Insights ouvre l’index Figma 1:6839, et comment accède-t-on aux Customer Stories et aux Use cases ?
• La page Figma Partners doit-elle s’appeler Technologies, et les deux accès Technology partners / Keyrus accelerators mènent-ils à une seule page ou à deux pages distinctes ?
• Quels types éditoriaux distincts valide-t-on dans le CMS, et comment agrège-t-on articles, stories, use cases, vidéos et événements dans les listings ?
• Où la page Locations doit-elle apparaître dans la navigation finale ?
• Le lien doit-il s’appeler Locations, Offices, Our locations ou porter un autre libellé ?
• Faut-il un index /{lang}/locations distinct de la carte déjà présente sur la homepage ?
• Quels pays auront une page dédiée au lancement, et qui maintiendra leurs contenus ?
• Quels liens LinkedIn et e-mails publics peut-on afficher sur les onze cartes de dirigeants France ?
• Quels vrais événements France remplacent les trois aperçus Figma, et le CTA doit-il mener vers Events ou Insights ?
• Quelles dates complètes, destinations d’inscription et règles d’archive faut-il appliquer au listing Events ?
• La carte mondiale de la homepage doit-elle renvoyer vers les pages pays ou rester centrée sur les bureaux ?
• Traduit-on les slugs éditoriaux, les segments de route, les deux ou aucun des deux dans les quatre langues ?
• Quelles pages disposent de traductions réelles et quelles anciennes URL doivent conserver leur chemin ou être redirigées ?
• Quelle description doit remplacer le texte Finance dupliqué sur la carte Data & technology leaders du template Services ?
• Quelles études de cas réelles illustrent Advise, et où doivent mener les cartes et le bouton View all customer stories ?
• Quelles réponses FAQ manquent pour Advise, et quel formulaire Contact validé faut-il brancher au CTA ?