Résumé

  • Le test 3.1 du rapport préliminaire sur Milan porte sur la possibilité, pour 80 % des participants IETF, d’obtenir un visa sans effort ni coût excessifs. Sa justification répond au critère distinct de non-discrimination du test 3.2 ; les deux lignes sont néanmoins vertes.
  • Cette discordance établit un défaut de traçabilité publique, pas l’échec de Milan. Une étude interne a pu être menée et le rapport peut encore être corrigé ou complété pendant la consultation.
  • Le rapport parallèle sur Montevideo sépare bien les deux réponses : il traite le seuil de 80 % à la ligne 3.1 et la non-discrimination à la ligne 3.2. Ce témoin porte sur la structure du dossier, non sur la ville à choisir.
  • Daniel Kade propose un reçu critère-preuve qui accompagne chaque statut : question exacte, source, calcul, date d’observation, incertitude, auteur de l’évaluation, historique des révisions et étape de décision.

Deux lignes, une seule justification

Le rapport Milan a été établi le 9 juillet 2026. Il étudie notamment Allianz MiCo et passe en revue neuf tests : capacité du lieu, accès Internet, visas, risques de voyage, santé, qualité de l’air, troubles politiques et expérience vécue de la discrimination. Son bilan annonce huit critères satisfaits, aucun incertain, aucun non satisfait et un non évalué. Une légende visuelle fait le reste : vert pour « satisfait », jaune pour « incertain mais possible », rouge pour « non satisfait », gris pour « impossible à évaluer ».

À première vue, cette concision est une force. Une équipe peut repérer rapidement un obstacle rédhibitoire et décider si des recherches coûteuses doivent continuer. Mais la concision n’est utile que si chaque couleur reste attachée à son objet.

La ligne 3.1 pose une question mesurable : les exigences de visa permettent-elles à 80 % des participants IETF d’obtenir un visa sans effort ou coût excessifs ? La réponse attendue doit donc parler d’une population de référence, de pays de départ, d’entrée sans visa ou par procédure ordinaire, ainsi que d’un seuil d’effort et de coût. Le modèle officiel suggère exactement cette construction.

Le texte publié pour Milan affirme à la place que les règles italiennes de visa ne sont pas discriminatoires selon la race, l’origine ethnique, la religion, le genre, l’orientation sexuelle ou l’identité de genre. Il renvoie au ministère italien des Affaires étrangères. Cette phrase convient à la ligne 3.2, qui formule cette question de non-discrimination et répète à peu près le même texte et le même lien. Les deux lignes reçoivent une case verte.

Le lecteur ne trouve donc, à la ligne 3.1, ni répartition des participants par pays, ni pourcentage calculé, ni distinction entre dispense et procédure standard, ni coût jugé raisonnable, ni traitement des données manquantes. Il ne peut pas reproduire la conclusion. Cela ne démontre pas que le calcul n’a jamais existé. Il peut s’agir d’une phrase copiée au mauvais endroit. Cela ne démontre pas non plus que le seuil ne serait pas atteint. La seule affirmation solide est documentaire : la justification visible ne répond pas au test qu’elle est censée soutenir.

Montevideo montre la grammaire attendue

Le rapport de Montevideo, daté du même jour et construit sur le même modèle, permet de comprendre la différence sans recourir à une théorie. À sa ligne 3.1, il dit que 80 % des participants, répartis par pays, peuvent entrer en Uruguay sans visa ou par une procédure standard à coût raisonnable. À la ligne 3.2, il traite séparément la non-discrimination des règles de visa.

Cette comparaison ne donne aucun classement. Montevideo laisse deux tests sans évaluation — la qualité de l’air faute de données suffisantes et l’expérience vécue de la discrimination en attente de retours. Son bilan est de sept verts et deux gris. Milan en a huit et un. Additionner les couleurs ne suffit pas à choisir une ville, et aucun des deux documents ne recommande encore d’accepter ou de rejeter.

Montevideo sert seulement de témoin interne : le format sait distinguer l’accès quantitatif et la non-discrimination qualitative. Le doublon de Milan n’est donc pas imposé par une ambiguïté du modèle.

Le témoin révèle aussi une amélioration possible pour les deux villes. La phrase de Montevideo répond à la bonne question, mais elle n’expose pas son calcul. Un résultat de 80 % possède l’apparence de la précision. Pour la mériter, le dossier pourrait publier de façon agrégée les réunions de référence, la répartition par pays, les voies d’entrée retenues, les frais ordinaires, les cas manquants et le résultat. Aucun nom, passeport ou historique individuel ne serait nécessaire.

L’absence de recommandation est normale

La section « Recommandation » des deux rapports n’est pas vide par négligence. Le modèle IETF explique qu’un rapport préliminaire ne dispose que d’informations partielles et n’émet donc aucune recommandation. Les avis de la communauté et les recherches qu’ils déclenchent doivent nourrir la version finale.

L’appel du 14 août suit ce schéma. IETF Administration LLC y présente Milan et Montevideo comme des villes envisagées, chacune « sans recommandation ». Les contributions doivent passer par une adresse dont les messages sont publiquement consultables et sont également regroupées sur un tableau Trello. La clôture était annoncée pour le 28 août 2026. À la date d’observation, parler d’approbation, de rejet ou de réservation contractuelle serait donc prématuré.

Les cases grises illustrent la fonction de cette étape. Le test 6.1 demande si la ville est dangereuse pour des participants à cause de discriminations, en s’appuyant sur leur expérience vécue. Pour les deux villes, le rapport réclame un retour communautaire. Un chercheur à distance ne peut pas déduire une expérience vécue d’un avis diplomatique. Ici, reconnaître l’absence de preuve est une bonne discipline, pas une faiblesse.

Après la consultation, l’administration peut approfondir ses recherches, modifier une appréciation puis publier une recommandation d’approbation ou de rejet. Un rejet clôt la piste. Une approbation ouvre seulement les étapes suivantes : étude détaillée, visites éventuelles, coûts, hôtels, appui local et disponibilité. Si des préoccupations portent sur les raisons fondamentales de se réunir, l’IESG peut intervenir dans son propre rôle. Le Board de l’IETF LLC examine plus tard un dossier confidentiel ; le contrat et l’annonce publique viennent encore après.

Chaque passage engage une autorité distincte. Une case verte n’est pas la recommandation de l’Executive Director. Une recommandation n’est pas une inspection commerciale. L’évaluation de l’IESG n’est pas l’autorisation du Board. L’autorisation du Board n’est pas le contrat. Le rapport initial est précieux parce qu’il transmet des preuves entre ces étapes, non parce qu’il les remplace.

D’un principe général à un seuil de 80 %

Le RFC 8718 demande à l’IASA d’exercer son meilleur jugement, d’ouvrir le processus autant que possible et de consulter assez tôt pour que la communauté puisse encore influer avant la conclusion d’un contrat. Parmi les critères importants figure l’idée que les obstacles à l’entrée, visas compris, doivent permettre à une majorité écrasante des personnes souhaitant venir de le faire. Le texte invite à comprendre largement ces obstacles selon les conditions d’une réunion réussie.

Le modèle administratif traduit « majorité écrasante » par 80 %. Cette opérationnalisation est saine : elle empêche un adjectif confortable de changer de sens d’une ville à l’autre. En revanche, elle oblige à préciser le dénominateur et la méthode. Une question exacte accompagnée d’une réponse opaque ne produit pas une évaluation exacte.

Qui compte comme « participant IETF » ? Les inscrits des trois dernières réunions, les individus uniques, les présences par réunion ou une prévision régionale ? Utilise-t-on la nationalité, le pays de résidence ou l’origine habituelle du voyage ? Comment classe-t-on une procédure standard, un rendez-vous consulaire rare, un prix supportable pour une entreprise mais pas pour un contributeur autonome ? Il n'appartient pas à cet article de choisir. Le devoir du rapport est de nommer le choix effectué.

Une publication agrégée protège à la fois la vie privée et la crédibilité. Elle peut donner la période de référence, les effectifs par pays, la source officielle des règles, la catégorie de procédure, les hypothèses de coût, les exceptions et la proportion obtenue. Le public vérifie alors une méthode, pas la situation personnelle d’un voyageur.

Corriger sans dramatiser, conserver sans effacer

La consultation publique est le bon endroit pour signaler le décalage. Un commentaire utile peut citer la version du rapport, désigner la ligne 3.1, constater que son texte répond à 3.2, demander le calcul correspondant ou un changement de statut et préciser qu’il ne conclut rien sur la ville. Une telle formulation facilite une réparation locale.

Le RFC 8711 prévoit aussi une voie formelle : tout participant peut demander au Board de revoir une décision ou une action de l’Executive Director ou du Board s’il estime qu’elle contrevient aux BCP ou aux politiques de la LLC. La demande doit identifier l’action, le manquement allégué et une solution ; la LLC doit rendre publics la demande et son résultat. Cette procédure n’est pas le guichet ordinaire pour corriger un rapport encore préliminaire. La consultation est antérieure, plus légère et proportionnée.

Une institution mûre ne transforme pas chaque erreur de champ en crise constitutionnelle. Elle ne la dissimule pas non plus. La correction devrait laisser une note : l’ancienne justification de 3.1 reprenait celle de 3.2 ; voici la source ou le calcul désormais attaché ; le statut reste vert, change ou demeure indéterminé ; voici la date et la raison.

Cette trace évite deux pertes. D’abord, les participants voient que leur contribution a modifié le dossier. Ensuite, les décideurs futurs savent si la conclusion était stable, nouvellement étayée ou révisée. Une correction silencieuse rend la page plus propre ; une correction attribuée rend le processus plus fiable.

Le reçu critère-preuve

Daniel Kade propose un petit reçu associé à chaque ligne. Il ne s’agit pas d’une règle IETF existante, ni d’un nouvel organe de contrôle. Le reçu transporterait seulement ce qu’une couleur ne peut contenir.

Il commencerait par la source normative et sa version : critère du RFC, mise à jour éventuelle, version du modèle. Il conserverait ensuite le numéro du test et sa formulation exacte. Il préciserait le périmètre — pays, ville ou lieu —, le sujet et la date limite d’observation.

La partie centrale relierait chaque preuve à la question. Pour un calcul, elle indiquerait population, pondération, seuil, valeurs manquantes et exceptions. Pour une source externe, elle donnerait la date de consultation et expliquerait en une phrase sa pertinence. Le statut et l’incertitude seraient inscrits ensemble : « satisfait » avec sa base, ou « impossible à évaluer » avec l’information attendue.

Le reçu nommerait aussi le responsable et l’étape : évaluation initiale du Secretariat, rapport préliminaire, rapport final révisé ou dossier ultérieur. Enfin, il conserverait la chronologie : texte précédent, retour reçu, correction, changement de couleur et décision en aval. Recommandation, recherche détaillée, éventuel examen IESG, autorisation du Board et contrat resteraient des événements séparés.

Les limites sont aussi importantes que le contenu. Pas de parcours individuels de visa, de caractéristiques protégées, de retours privés, d’offres commerciales ou de dossier confidentiel du Board. Le reçu ne crée pas de vote populaire et ne retire pas sa compétence à la LLC. Il rend seulement vérifiable la liaison entre une preuve et l’autorité qui s’en sert.

Ce que l’on peut conclure au 28 août

Le dossier public permet d’affirmer que la ligne 3.1 de Milan contient une justification qui ne correspond pas à sa question et qui réapparaît sous 3.2. Il permet de constater que les deux lignes sont vertes et que le modèle ainsi que le rapport Montevideo attendent deux réponses distinctes.

Il ne permet pas d’affirmer que Milan se situe sous 80 %, que sa case doit être rouge, que Montevideo est préférable ou que l’administration ne possède aucune analyse interne. Il ne permet pas davantage de prévoir la recommandation finale. L’enjeu présent est plus précis : réparer le lien public entre critère et preuve tant que la décision reste réversible.

Les grandes décisions administratives commencent souvent par de petites cellules. Lorsque la cellule répond à sa question, la discrétion ultérieure reste discutable et attribuable. Lorsqu’elle n’y répond pas, la couleur hérite d’une autorité qu’elle n’a pas gagnée. Une case verte peut résumer une preuve ; elle ne peut pas la remplacer.

Limites des éléments disponibles

L’analyse repose sur les deux rapports préliminaires, le modèle actuel, l’appel à contributions, les pages de planification et les RFC 8718, 8711 et 9712. Elle ne dispose pas des notes internes du Secretariat, du calcul par pays, des retours privés, du contenu complet du tableau Trello, des offres commerciales ni d’un rapport final ultérieur. Elle ne peut trancher la disponibilité commerciale ou le choix final d’une ville.

L’absence de calcul dans le document est un constat de publication, pas la preuve que personne ne l’a effectué. Montevideo montre la sémantique attendue mais ne valide pas son propre chiffre et n’établit aucun classement. Le reçu proposé relève de l’analyse de Daniel Kade.

Sources

  1. Appel à contributions sur Montevideo et Milan
  2. Rapport d’évaluation de Milan
  3. Rapport d’évaluation de Montevideo
  4. Modèle IETF Venue Assessment Report v3
  5. Processus de sélection des lieux de réunion IETF
  6. Tableau des évaluations de villes
  7. RFC 8718 : choix des lieux des réunions plénières
  8. RFC 8711 : structure d’IASA 2.0
  9. RFC 9712 : révision des exigences relatives aux lieux