1. Ce que SDF v11 change dans les opérations
Les Structured Data Files servent à exporter, modifier et réimporter en volume des objets Display & Video 360. Leur efficacité vient précisément de leur puissance : une modification correcte peut industrialiser un réglage sur des centaines de lignes ; une erreur peut industrialiser le mauvais réglage tout aussi vite.
Le 9 octobre 2026, Search Engine Land a présenté la disponibilité générale de SDF v11. Google documente notamment la prise en charge élargie des audiences similaires en inclusion et exclusion, le ciblage de proximité autour de chaînes d’établissements et des évolutions de colonnes liées aux fournisseurs tiers sur YouTube.
La version introduit aussi des champs et restrictions pour les Instant Deals YouTube, qui restent limités aux partenaires autorisés et suivent un workflow particulier. Cela signifie qu’un modèle universel appliqué sans distinction aux différents types de lignes n’est pas une stratégie sûre.
À retenir
SDF v11 n’est pas seulement une nouvelle nomenclature. C’est un changement de contrat entre vos fichiers, vos scripts et l’API d’import DV360. Chaque exception doit être considérée comme une règle de validation.
2. Inventorier avant de modifier
Commencez par localiser tous les producteurs et consommateurs de SDF : exports manuels, scripts Python, feuilles de calcul, connecteurs ETL, modèles d’agence et contrôles internes. Notez pour chacun la version utilisée, les types d’entités manipulés, le propriétaire et la fréquence d’exécution.
L’échéance importante concerne les versions antérieures à v10, annoncées comme non prises en charge à partir de janvier 2027. Le risque n’est donc pas seulement qu’un nouvel import échoue. Un processus oublié peut continuer à générer silencieusement un format ancien jusqu’au jour où il bloque une opération urgente.
Construire une matrice de dépendances
Pour chaque colonne utilisée, indiquez sa source, sa transformation, sa valeur par défaut et le contrôle appliqué. Cette matrice révèle les champs codés en dur, les listes de valeurs anciennes et les étapes qui supposent une position de colonne plutôt qu’un nom explicite.
3. Traiter le schéma comme un contrat versionné
La migration doit comparer les schémas, pas seulement les noms visibles. Contrôlez le type attendu, les valeurs autorisées, les colonnes retirées, les nouvelles dépendances et les exceptions par format. Une colonne déplacée ou supprimée peut casser un parseur positionnel sans produire une erreur lisible.
Créez un mapping v10 → v11 séparé du code métier. Le script doit refuser une colonne inconnue ou une valeur non prévue au lieu de la remplacer silencieusement. Pour les champs de ciblage, vérifiez que l’inclusion et l’exclusion restent cohérentes après transformation.
Les notes de version et le guide de migration Google doivent devenir des références de test. Ajoutez leurs règles importantes à une suite automatisée : présence des en-têtes obligatoires, unicité des identifiants, formats de statut, compatibilité du type de ligne et valeurs de ciblage.
4. Déployer par lots avec un diff lisible
Préparez un environnement de staging avec un export réel mais limité. Transformez le fichier, puis produisez un diff lisible par les équipes média : objets ajoutés, supprimés ou modifiés, anciennes et nouvelles valeurs, et lignes exclues du traitement.
Le premier import doit viser un périmètre réversible : quelques campagnes non critiques, un nombre limité de line items et aucune modification simultanée de budget majeur. Après import, réexportez les mêmes objets depuis DV360 et comparez la valeur persistée à la valeur demandée.
Cette lecture retour est essentielle. Un import accepté prouve que le fichier a été traité ; il ne prouve pas que chaque champ a produit l’effet attendu. Conservez le fichier avant migration, le fichier envoyé, le rapport d’erreur et l’export après import.
5. Prévoir les échecs avant le passage en production
Erreurs à éviter
- Remplacer uniquement le numéro de version sans comparer les schémas.
- Supposer que tous les types de campagnes acceptent les mêmes colonnes.
- Ignorer les exceptions des YouTube Ad Sequence et Instant Deals.
- Importer un fichier complet sans diff, lot témoin ni export de contrôle.
- Attendre décembre 2026 pour découvrir les processus encore antérieurs à v10.
Le rollback doit être préparé avant l’import. Définissez quels objets peuvent être restaurés depuis l’export précédent, qui peut arrêter le pipeline et comment empêcher une exécution planifiée de réappliquer le mauvais fichier.
6. Plan d’action 24/48 h
Plan d’action 24/48 h
- Listez tous les scripts, modèles et connecteurs qui lisent ou produisent des SDF.
- Identifiez les versions inférieures à v10 et attribuez un propriétaire à chaque migration.
- Téléchargez les schémas v10 et v11, puis construisez un mapping explicite des champs utilisés.
- Ajoutez des validations bloquantes et un diff avant tout import.
- Choisissez un lot pilote, préparez le rollback et planifiez un export de contrôle après import.
SDF v11 apporte davantage de flexibilité aux opérations DV360, mais sa valeur dépend de la qualité du pipeline qui l’entoure. Une migration maîtrisée ne se résume pas à « le fichier passe ». Elle prouve que les valeurs attendues ont été enregistrées, que les exceptions sont couvertes et qu’un retour arrière reste possible.