Le projet de traduction de l’IRP d’ICANN impose de demander l’aide en anglais

Résumé

• Au moment de cette analyse, l’index des consultations publiques d’ICANN classait le dossier IRP-IOT parmi les rapports attendus, avec une échéance au 1er septembre 2026 et neuf contributions. La rubrique « Outcome » restait vide.
• Les statuts d’ICANN font de l’anglais la langue de travail principale de l’IRP, tout en exigeant des services de traduction lorsque le demandeur en a besoin.
• La règle provisoire de 2018 autorise la demande de traduction dans une autre langue lorsque son dépôt en anglais constituerait une charge excessive.
• Le projet de Rule 5B exige au contraire que l’exposé du litige et la demande de services linguistiques soient tous deux soumis en anglais.
• Le projet apporte aussi des progrès réels : langues non onusiennes lorsque cela est nécessaire, décision urgente, coûts assumés par ICANN et délais ajustables.
• Une demande préliminaire multilingue, accompagnée d’un reçu précis, protégerait l’entrée sans transformer l’anglais en langue secondaire ni préjuger le fond.

La date d’un rapport ne vaut pas décision

L’IRP est l’un des mécanismes qui permettent de contester une action couverte d’ICANN au regard de ses statuts ou de ses Articles of Incorporation. Les statuts présentent cet examen externe comme accessible, abordable et confié à des experts. Ils fixent en même temps une règle pratique : la procédure fonctionne principalement en anglais, avec une assistance linguistique fondée sur le besoin.

L’IRP Implementation Oversight Team a soumis en 2024 plusieurs modifications à consultation. Elles concernent notamment la composition des panels, les délais, la traduction et la participation de tiers. Neuf réponses sont publiques. L’index actuel annonçait un rapport pour le 1er septembre 2026, mais aucun résultat n’était publié à la clôture de cette analyse.

Il faut donc employer le futur et le conditionnel avec rigueur. Le texte étudié n’a pas remplacé la règle provisoire. L’échéance du rapport ne dit rien de son contenu. Elle donne néanmoins une actualité à une différence précise entre les deux versions.

Une parenthèse de 2018 protège l’accès

La Rule 5B provisoire ne donne pas libre choix de langue pour tout le contentieux. Le panel apprécie le besoin, délimite les documents ou audiences concernés et choisit la langue. En l’absence d’une reconnaissance du besoin, les pièces doivent être en anglais. La liste ordinaire ne comprend que l’anglais et les cinq autres langues officielles de l’ONU : arabe, chinois, espagnol, français et russe.

Une exception très ciblée change toutefois l’ordre des opérations. Le demandeur peut présenter la requête de traduction dans une autre langue s’il certifie que la rédiger en anglais serait excessivement contraignant.

Cette faculté ne lance pas automatiquement une procédure non anglophone. Elle ne suspend pas un délai, n’établit pas la qualité pour agir et n’oblige pas ICANN à traduire le dossier. Elle permet seulement au décideur compétent de prendre connaissance de l’obstacle avant d’exiger qu’il soit surmonté.

L’exception occupe peu de place dans le document. Dans l’architecture institutionnelle, elle constitue pourtant le seuil.

Le nouveau dispositif est plus généreux après le seuil

Le projet détaille beaucoup mieux les services possibles. Il vise les mémoires, les pièces matériellement pertinentes, les transcriptions, les décisions du panel et l’interprétation orale. Il prévoit le remboursement de la traduction en anglais de l’exposé initial dans certaines conditions et la traduction de la réponse d’ICANN vers la langue préférée du demandeur.

Une demande urgente pourrait être examinée par un paneliste d’urgence avant la constitution du panel complet. Les prestations ordonnées seraient coordonnées par les fournisseurs linguistiques d’ICANN et payées comme frais administratifs, sauf décision ultérieure contraire. Le calendrier des dépôts et d’un éventuel appel pourrait être adapté au temps de traduction.

Le projet corrige aussi une limite de la règle actuelle. Il privilégie une langue officielle de l’ONU lorsqu’elle permet une participation équitable, mais n’exclut plus une autre langue lorsqu’elle est nécessaire. Une personne qui ne maîtrise ni l’anglais ni l’une des cinq autres langues pourrait donc, en principe, recevoir une aide appropriée.

Ce sont des avancées substantielles. Elles rendent le contraste avec l’entrée d’autant plus important.

La preuve du besoin doit d’abord exister en anglais

Le projet exige que l’exposé du litige soit en anglais. Il exige ensuite que la demande de traduction soit également en anglais, qu’elle nomme la langue préférée, explique le besoin, décrive les compétences linguistiques du demandeur ou de son représentant et tienne en cinq pages à double interligne.

Le texte précise fort justement qu’un dépôt en anglais ne permettra pas de conclure que la traduction est inutile. Une personne ne perd donc pas son droit potentiel parce qu’elle a réussi à respecter l’exigence initiale.

Mais cette garantie intervient une étape trop tard. Celui qui peut engager un avocat anglophone ou acheter une traduction certifiée franchit le seuil, puis demande une prise en charge. Celui qui ne dispose pas de cette ressource doit résoudre seul le problème que le mécanisme public est censé évaluer.

Le Non-Commercial Stakeholder Group a formulé une critique voisine. Tout en soutenant la Rule 5B, il estime qu’une aide accessible uniquement sur demande pèse sur les non-anglophones qui peuvent ignorer l’existence de ce droit. Il recommande une information et une offre proactives au début de la procédure.

Cette contribution n’est ni un constat d’ICANN ni un consensus. Aucune source examinée ne prouve qu’une personne a déjà été écartée par le projet. Le danger tient précisément à l’absence possible de trace : renoncement, coût initial, erreur de cadrage ou retard peuvent intervenir avant qu’un panel ne rende une décision.

Séparer le signalement linguistique du mémoire au fond

La réponse proportionnée n’est pas la traduction automatique de chaque page. Les statuts conservent l’anglais comme langue de travail, et le panel doit pouvoir concentrer les moyens sur les besoins réels. Une simple demande en langue étrangère ne doit pas non plus être présentée comme un mémoire complet ou comme une garantie de suspension des délais.

ICANN peut créer un sas beaucoup plus étroit. Une personne envoie un bref signalement dans une langue identifiable. Le système date la réception, attribue un identifiant et répond dans cette langue, si possible. Le reçu indique ce qui a été reçu, ce qui ne constitue pas encore un dépôt valable, quels délais continuent, si une protection provisoire existe et qui décidera de l’assistance.

Le texte original doit être conservé à côté de sa version anglaise certifiée ou produite par le prestataire. Une correction s’ajoute au dossier ; elle ne remplace pas silencieusement la première formulation. Le chemin vers le paneliste d’urgence et toute acceptation directe d’ICANN doivent apparaître comme des états distincts.

La transparence publique peut rester agrégée : langues demandées, acceptations, refus, délais de réponse, durée des traductions et coûts. L’absence de demandes dans une communauté ne prouverait pas l’absence de besoin ; elle déclencherait un contrôle de l’information et de l’interface.

Cette solution applique avec mesure la distinction de Heng Lu entre participation et mandat. Recevoir un signalement n’accorde aucun pouvoir au demandeur et ne valide pas son litige. Cela permet simplement à l’autorité compétente, et non à la langue du guichet, de décider si l’aide est due.

Moderniser sans supprimer la première porte

Comparer les deux textes par une note globale serait trompeur. Le projet est plus ouvert après l’acceptation du besoin : davantage de langues, des frais mieux définis, une voie urgente et des calendriers adaptables. Il est moins ouvert au moment exact où ce besoin doit être exprimé.

Préserver l’exception actuelle sous la forme d’un reçu multilingue ne remet pas en cause l’anglais. La mesure ne présume ni le besoin, ni la recevabilité, ni le fond. Elle remet seulement les opérations dans un ordre cohérent : identifier l’obstacle, décider de l’assistance, puis construire le dossier anglais dont la procédure a besoin.

Un mécanisme de responsabilité ne devrait pas exiger qu’une personne surmonte seule une barrière avant de pouvoir signaler cette barrière. La règle provisoire l’avait compris en une phrase. La prochaine version devrait rendre cette protection plus visible, pas la faire disparaître.

Sources

1. Index des consultations publiques d’ICANN
2. Consultation sur les modifications IRP-IOT
3. Projet propre des règles modifiées
4. Projet comparé et motivations de l’IRP-IOT
5. Procédures supplémentaires provisoires de 2018
6. Contribution du NCSG
7. Statuts d’ICANN, article 4.3
8. Heng Lu, The Multi-Stakeholder Mirage