Gouverner la mise en ligne d’un site IA avec Baseline

Web Platform Baseline aide à déterminer si une fonctionnalité front-end est interopérable dans les principaux navigateurs. Web.dev distingue la prise en charge limitée à certains navigateurs, le statut Newly available lorsque l’ensemble principal assure l’interopérabilité, puis le statut Widely available après 30 mois. L’ensemble principal comprend Chrome sur ordinateur et Android, Edge, Firefox sur ordinateur et Android, ainsi que Safari sur macOS et iOS.

Pour un site produit avec l’aide de l’IA, ce statut est une entrée de la décision, pas une garantie de résultat. Il ne prouve ni le fonctionnement d’un formulaire, ni l’accessibilité d’un composant, ni la réception d’une demande. L’interprétation opérationnelle de CreatikLab consiste à associer Baseline à une politique de navigateurs, à des tests de parcours, à un registre des exceptions et à une validation des données commerciales.

Web.dev indique que l’équipe Chrome a lancé Baseline et que le WebDX Community Group en assure désormais la définition. Le dispositif rend plus lisible le niveau de prise en charge des fonctionnalités de la plateforme web. Tant que l’interopérabilité n’est pas atteinte dans tout l’ensemble principal, une fonctionnalité peut rester indiquée comme disponible dans certains navigateurs seulement. La disponibilité étendue ajoute le délai documenté de 30 mois.

La page présente également plusieurs intégrations. Lighthouse peut détecter les fonctionnalités employées sur une page et afficher leur statut Baseline. Browserslist prend en charge des requêtes Baseline, Visual Studio Code fournit des informations correspondantes et le paquet web-features permet de développer un outillage personnalisé. Web.dev mentionne aussi Chrome DevTools et un Baseline Checker pouvant exploiter des données Google Analytics pour guider le choix d’une cible. Ces outils décrivent des fonctionnalités, pas la qualité complète d’un site.

CreatikLab commence par une fiche de parcours plutôt que par une conclusion générale sur le site. La fiche nomme l’objectif utilisateur, le résultat attendu, les environnements à couvrir, les composants sollicités et le système qui confirme l’opération. Elle permet de relier un signal Baseline à une conséquence observable.

• Objectif : demande de contact, réservation, achat, connexion ou opération de compte.
• Point de contrôle : interaction, validation, consentement, envoi, confirmation et réception aval.
• Dépendance technique : fonctionnalité web, bibliothèque, script tiers ou service connecté.
• Preuve : rapport, capture, journal, étapes reproductibles et enregistrement dans le système destinataire.
• Décision : accepter, remplacer, améliorer progressivement, fournir un repli ou suspendre la mise en ligne.
• Responsabilité : auteur de la correction, approbateur et propriétaire de la non-régression.

Cette fiche relève de la méthode CreatikLab et non d’une règle de Google. Elle empêche qu’un état de fonctionnalité soit confondu avec un test de bout en bout. Elle permet aussi de distinguer un problème sans impact commercial d’un défaut qui bloque une demande, une commande ou un accès essentiel.

La même fonctionnalité peut exiger des traitements différents selon son rôle. Une amélioration visuelle non essentielle peut accepter une dégradation contrôlée. Un contrôle indispensable à l’envoi d’un formulaire demande une preuve plus forte. L’arbitrage examine donc séparément le statut Baseline et la criticité du parcours.

• Widely available et usage secondaire — conserver avec la régression habituelle, sauf contrainte propre au projet.
• Widely available et parcours critique — tester le parcours complet dans les environnements retenus avant acceptation.
• Newly available — documenter le besoin, le comportement de repli et l’approbation technique et produit.
• Prise en charge limitée — retirer du chemin critique en l’absence d’une alternative vérifiée.
• Statut inconnu — suspendre l’acceptation automatique et organiser la recherche ainsi que les essais manuels.

La règle de décision est proportionnelle : plus l’échec est dommageable et moins l’interopérabilité est mature, plus les preuves et la solution de repli doivent être robustes. Baseline ne fixe pas le niveau de risque qu’une organisation doit accepter. Le propriétaire du produit doit approuver ce seuil en fonction des utilisateurs et des engagements réels.

1. Définir la politique de navigateurs et d’appareils à partir du public et des obligations du projet, sans remplacer automatiquement cette politique par l’ensemble Baseline.
2. Inventorier les pages et les parcours majeurs, puis décrire pour chacun le résultat attendu et le système qui le confirme.
3. Exécuter l’audit Baseline de Lighthouse sur des pages représentatives et conserver le rapport avec la version examinée.
4. Configurer des requêtes Baseline dans Browserslist lorsqu’elles conviennent à la chaîne de construction, puis versionner la cible choisie.
5. Examiner les fonctionnalités détectées et consigner leur statut, leur rôle dans le parcours et les environnements concernés.
6. Décider pour chaque exception de conserver, remplacer, améliorer progressivement ou fournir un repli, avec une justification explicite.
7. Tester les parcours critiques dans les combinaisons prévues et enregistrer l’environnement, les étapes, les résultats et les preuves.
8. Ajouter la non-régression, nommer un responsable et rouvrir l’examen après une modification significative du code ou des dépendances.

Web.dev n’impose pas cette séquence. Elle constitue un cadre opérationnel CreatikLab destiné à rendre l’acceptation traçable. Un contrôle n’est terminé que lorsque l’observation possède un impact évalué, une action, un propriétaire et une preuve de clôture.

Une mesure utile distingue le fonctionnement technique du résultat commercial. L’équipe vérifie d’abord que le parcours produit le même résultat attendu dans les environnements pris en charge. Elle contrôle ensuite que la demande atteint le système prévu et peut être évaluée selon des critères métier documentés. Un événement de formulaire ne suffit pas à qualifier un prospect.

• Dimension technique : fonctionnalité, statut Baseline, navigateur, appareil, version, résultat et erreur constatée.
• Dimension parcours : démarrage, validations, consentement, envoi, confirmation et réception aval.
• Dimension données : paramètres de campagne, doublons, correspondance des champs et transmission au CRM.
• Dimension commerciale : demande acceptée ou refusée, motif, progression et responsable du retour.
• Dimension changement : exception créée, approbateur, condition de retrait et résultat de non-régression.

Le protocole doit être reproductible. Une preuve de formulaire indique le contexte de test, les étapes exécutées, le résultat visible et l’enregistrement reçu. Les soumissions de contrôle doivent pouvoir être séparées des demandes réelles. La qualification reste une décision métier ; elle ne se déduit ni du statut Baseline ni de la seule présence d’une conversion analytique.

Baseline ne mesure pas les revenus, les conversions ou la qualité d’une demande. Il apporte une information d’interopérabilité. CreatikLab relie cette information aux tests et aux données propriétaires sans fusionner les concepts. Un site compatible peut rester peu convaincant, tandis qu’un site générant des demandes peut encore cacher une panne propre à un navigateur.

• Widely available ne signifie pas que l’implémentation examinée est exempte de défauts.
• L’ensemble principal de Baseline ne couvre pas automatiquement chaque webview, appareil ou technologie d’assistance du public.
• Un rapport Lighthouse ne valide pas seul les paiements, formulaires, connexions, scripts tiers, outils analytiques ou transmissions CRM.
• Newly available ne signifie pas inutilisable ; ce statut exige une décision explicite et des tests proportionnés.
• Un correctif produit avec l’aide de l’IA n’est pas automatiquement accessible, équivalent ou maintenable.
• Le délai de 30 mois correspond à une étape de classification et non à une durée contractuelle de support.

La dérive de politique constitue un risque supplémentaire. Plusieurs développeurs peuvent employer des cibles différentes, ou une dépendance peut introduire une fonctionnalité non prévue. Une politique versionnée, une détection automatisée lorsque pertinente, des exceptions approuvées et des preuves conservées réduisent ce risque.

Il ne faut pas déduire d’un statut Baseline un prix, une durée de réalisation, un périmètre de déploiement, une règle d’éligibilité, une amélioration des performances commerciales ou une garantie universelle. Ces éléments nécessitent une analyse séparée du site, de son public, de ses dépendances et de ses parcours.

Un commanditaire peut demander une politique de support, un inventaire des pages et parcours, des rapports Lighthouse Baseline liés aux versions, un registre des fonctionnalités et risques, des anomalies reproductibles, un plan de correction, des responsables, des exceptions approuvées et les résultats de non-régression. Toute proposition d’implémentation doit détailler séparément les modifications de code, les replis, les contrôles de pipeline et la validation des parcours commerciaux critiques.

Pour comparer des prestataires, il faut demander quelles fonctionnalités seront examinées, quels environnements seront testés, comment les exceptions seront approuvées et quelle preuve confirmera la réception d’une demande dans le système prévu. Le propriétaire de la non-régression et les critères de clôture doivent également être identifiés avant l’acceptation du périmètre.

Consultez le service consacré à l’automatisation par IA et aux systèmes web sur mesure, puis transmettez à Lia le site, le public, la stack, les environnements requis et le parcours défaillant. Demandez-lui d’évaluer l’adéquation et de cadrer un livrable expert concret : une note de décision de compatibilité précisant la politique cible, les parcours critiques, les preuves attendues et les critères d’acceptation proposés. Lia pourra indiquer la suite appropriée après examen du système et de ses contraintes réelles.

Quelle décision Baseline peut-il éclairer ?

Baseline aide à déterminer le niveau d’interopérabilité des fonctionnalités de la plateforme web utilisées. L’équipe peut ensuite confronter ce statut à sa politique de support et au risque du parcours concerné.

Baseline garantit-il qu’un parcours fonctionne ?

Non. Il fournit une information au niveau des fonctionnalités. Le comportement du parcours, son accessibilité, ses intégrations et la transmission de ses données nécessitent des essais séparés.

Quand une fonctionnalité devient-elle Widely available ?

Web.dev indique que ce statut intervient 30 mois après l’interopérabilité dans l’ensemble principal de navigateurs. Ce jalon ne garantit pas tous les appareils ou navigateurs intégrés.

Quels navigateurs composent l’ensemble principal ?

La liste publiée comprend Chrome sur ordinateur et Android, Edge, Firefox sur ordinateur et Android, ainsi que Safari sur macOS et iOS.

Quel rôle Lighthouse peut-il jouer ?

L’audit Baseline de Lighthouse peut identifier des fonctionnalités employées sur une page et signaler leur statut. Il sert à orienter l’examen, pas à certifier seul la mise en production.

Quels livrables rendent l’audit inspectable ?

Une politique de support, un inventaire des parcours, des rapports liés aux versions, un registre des risques, des anomalies reproductibles, des décisions d’exception et des résultats de non-régression rendent le travail contrôlable.