Sujet : validation
-
Vérifier les contrats de paramètres substituables lorsqu'un agent traduit le texte d'une interface
Préserver le sens à l'exécution des paramètres substituables (placeholders) et des variantes de messages lors de la traduction du texte d'une interface, afin qu'une prose fluide n'introduise pas de substitutions cassées ni de cas manquants.
-
Arrêt anticipé : patience, validation et restauration des meilleurs poids
Considérer l'epoch d'arrêt comme un choix de modèle, surveiller un signal de validation distinct et différencier les derniers poids entraînés des meilleurs poids observés.
-
Numéros de téléphone E.164 : que stocker et ce qu’un validateur ne peut pas savoir
Stocker les numéros de téléphone sous forme de chaînes E.164 (signe plus, indicatif de pays et numéro national, avec au maximum 15 chiffres selon le plan de l’UIT), jamais comme des entiers ; conserver la saisie brute et la région utilisée pour l’analyse, valider à l’aide de métadonnées de plans de numérotation maintenues et accepter qu’un contrôle syntaxique ne dise pas si un numéro est attribué, joignable ou détenu par l’utilisateur.
-
Normaliser l'Unicode avant de comparer des identifiants
Choisir une politique de normalisation pour les identifiants lisibles par des humains, sans modifier les jetons opaques ni confondre des caractères visuellement similaires.
-
Résoudre les sélections de date de Jev par rapport à un calendrier de référence explicite
Garder l'interprétation des dates auditable en séparant les parties de date sélectionnées dans un document des hypothèses de calendrier utilisées pour assembler une date exploitable.
-
Utiliser des schémas JSON stricts aux frontières des outils
Valider structurellement les arguments d'un outil avant l'exécution, puis appliquer des contrôles d'autorisation et de ressources indépendants.
-
Valider les adresses e-mail : ce qu'un contrôle de syntaxe peut et ne peut pas dire
La RFC 5321 plafonne la partie locale à 64 octets et un chemin à 256 ; la norme HTML utilise délibérément une grammaire plus simple que la RFC 5322 pour input type=email ; les adresses internationalisées nécessitent SMTPUTF8 de bout en bout. Vérifier la syntaxe et les longueurs, consulter les enregistrements MX à l'inscription, confirmer la possession par un message, et ne jamais « corriger » une adresse automatiquement.
-
Les identifiants dotés d'une clé de contrôle réduisent les actions sur le mauvais enregistrement lorsque des agents les transcrivent
Hypothèse : lorsque des agents fondés sur des modèles de langage recopient des identifiants tirés de documents dans des appels d'outils, un schéma comportant une clé de contrôle validée par l'API réceptrice transforme la plupart des erreurs de transcription en rejets plutôt qu'en actions sur le mauvais enregistrement ; l'effet devrait être le plus marqué pour les identifiants numériques denses et négligeable pour les identifiants clairsemés tels que les UUID.
-
Vérifier qu'un artefact de build inspecté provient bien du changement en cours
Empêcher un agent d'accepter un fichier, un aperçu ou un paquet obsolète comme preuve que le changement de code source en cours a été construit et livré avec succès.
-
Clés de contrôle : ce que Luhn, l'ISBN-13 et le mod-97 de l'IBAN détectent, et ce qu'ils ne détectent pas
Une clé de contrôle est une redondance calculée à partir des autres caractères d'un identifiant, afin qu'une erreur de recopie soit détectée avant toute recherche : Luhn (modulo 10 sur des chiffres doublés en alternance) protège les numéros de carte, l'ISBN-13 utilise des poids alternés de 1 et 3, et l'IBAN utilise la méthode MOD 97-10 de la norme ISO/IEC 7064 avec deux chiffres. Ces méthodes détectent les erreurs sur un seul caractère et la plupart des transpositions de caractères adjacents, mais jamais un identifiant erroné qui reste néanmoins valide.
Lisible par machine : JSON