Résumé

  • L’avis du 28 août indique que l’ICANN résilie le Registrar Accreditation Agreement d’IPIP INC. au titre de l’article 5.5.4, avec une prise d’effet au 13 septembre 2026.
  • La décision invoque quatre manquements que l’ICANN dit non corrigés au 26 août : service RDAP, dépôts de données sous séquestre, frais d’accréditation et lien public vers la procédure de demande de divulgation.
  • Le même avis ouvre ensuite une rubrique distincte de « préoccupations supplémentaires », avant de traiter du transfert des noms, de la licence de logo et des obligations survivant à la résiliation.
  • Une fiche de disposition par sujet permettrait de conserver la catégorie, la règle, la preuve, la demande de correction, le délai, la réponse et l’état sans ouvrir le dossier confidentiel.

La résiliation est décidée, mais pas encore effective

L’avis porte la date du 28 août 2026. Il affirme que le contrat d’accréditation 2013 d’IPIP INC., registrar IANA no 3774, est résilié en application de l’article 5.5.4. Dans la même introduction, il fixe au 13 septembre la prise d’effet, soit 16 jours calendaires après la notification selon son calcul de l’article 5.6.

Cette articulation compte au 30 août. La décision n’autorise pas à écrire que la transition est achevée, qu’un registrar repreneur est déjà connu ou qu’un nombre déterminé de noms a été transféré. Le dossier public ne fait pas davantage état d’un arbitrage, d’un sursis ou d’une correction ultérieure. Une décision assortie d’une date future n’est pas encore la preuve de toutes ses conséquences opérationnelles.

La page publique des mesures de conformité relie l’avis de manquement du 5 août à son escalade en résiliation. C’est une chronologie d’exécution contractuelle, non un certificat de fin de transfert.

Quatre contrôles différents, quatre manquements nommés

L’ICANN explique qu’IPIP n’a pas corrigé avant le 26 août les manquements exposés le 5 août. Elle en énumère quatre comme toujours présents au 28 août.

Le premier concerne RDAP. Selon l’ICANN, le service devait fournir les données requises pour tous les noms gTLD actifs parrainés par le registrar et appliquer la version courante du guide technique et du profil de réponse. L’avis précédent précise qu’une URL de base était enregistrée, mais que les requêtes testées ne renvoyaient pas les données de ces noms.

Le deuxième porte sur l’absence de dépôts ponctuels auprès d’un agent de séquestre agréé, selon le calendrier, les conditions et le format prescrits. Le troisième est financier : des frais d’accréditation restaient dus. Le quatrième concerne la page d’accueil, où devait figurer un lien direct vers le mécanisme et la procédure de demande de divulgation de données d’enregistrement non publiques.

Réunir ces objets sous le mot « conformité » est commode, mais peu informatif. RDAP est un service public de consultation. Le séquestre protège un noyau de données de continuité. Les frais relèvent d’une obligation de paiement. Le lien de divulgation rend visible une voie de saisine prévue par l’article 10.1 de la Registration Data Policy.

Les règles sont vérifiables séparément. Le profil RDAP de février 2024 est obligatoire depuis le 21 août 2025. La spécification 2025 du séquestre des données de registrar est entrée en vigueur le même jour. La politique de données exige que la page de divulgation précise le format de la demande, la voie de réponse et le délai envisagé.

Les constatations propres à IPIP restent toutefois celles de l’ICANN. BTW n’a ni interrogé tout le portefeuille de noms, ni inspecté le compte de séquestre, ni audité les factures. La formulation exacte est donc : l’ICANN a constaté et publié ces quatre manquements.

« En outre » ouvre une autre catégorie

Après cette liste, le texte change de registre. « En outre », écrit-il, IPIP n’a pas traité et résolu des « préoccupations supplémentaires ».

Elles portent sur un formulaire ou une adresse dédiée aux signalements d’abus, la procédure de traitement et de suivi de ces signalements, l’identité et les fonctions des dirigeants, l’adresse de correspondance, les politiques de suppression et de renouvellement automatique, les frais de restauration, les méthodes de notification du renouvellement et les mesures correctives assorties de dates de mise en œuvre.

Rien ne permet de qualifier ces sujets d’anodins. Plusieurs renvoient à des obligations expresses du RAA. Le choix du mot « préoccupation » ne garantit pas non plus qu’un sujet ne puisse jamais recevoir une qualification contractuelle différente. Mais le document ne les incorpore pas à la phrase précédente qui nomme les quatre manquements restant à corriger.

La prudence joue dans les deux sens. Affirmer que ces points n’ont aucune portée juridique dépasserait le texte. Les additionner automatiquement aux quatre motifs exposés comme si l’ICANN les avait tous qualifiés de manquements autonomes le dépasserait aussi.

L’avis ne hiérarchise pas davantage les quatre premiers. L’article 5.5.4 prévoit une résiliation lorsqu’un registrar ne corrige pas un manquement dans les 21 jours suivant notification. Le public sait que l’ICANN dit en avoir trouvé quatre non corrigés; il ne sait pas lequel aurait été décisif isolément. Une synthèse ne doit pas inventer cette causalité.

Les tentatives de contact établissent un parcours, pas une intention

Les chronologies annexées remontent à mars et juin. L’ICANN y décrit des avis escaladés ou successifs, des courriels rejetés, des absences de réponse, des appels téléphoniques et une réponse qu’elle a jugée insuffisante. L’avis formel du 5 août fixait le 26 août comme échéance. Une remise par courrier a été confirmée le 7 août; des rappels ont suivi le 19 août; le 28 août, l’ICANN a conclu que la correction requise n’était pas intervenue.

Ces éléments documentent les tentatives de notification, le délai et l’évaluation de la réponse par l’ICANN. Ils n’expliquent pas pourquoi certains messages ont été rejetés. Ils ne prouvent ni abandon, ni insolvabilité, ni fraude, ni incident de sécurité, ni volonté délibérée de se soustraire au contrat.

La meilleure défense de la concision du système tient à sa nature contractuelle. Un avis public n’a pas à reproduire toutes les communications internes et ne doit pas divulguer des coordonnées personnelles, des données de clients ou un avis juridique protégé. Mais la concision n’oblige pas à mélanger les statuts.

Après les motifs viennent les conséquences

Une troisième famille apparaît ensuite. L’ICANN annonce l’application de la De-Accredited Registrar Transition Procedure afin de transférer les noms gérés par IPIP à un registrar qualifié. La licence d’utilisation du logo prendra fin le 13 septembre. Certaines clauses — conservation des données, frais, règlement des différends et limites des réparations pécuniaires — survivent à la résiliation. Des frais passés et futurs définis dans l’avis restent dus.

Il s’agit d’effets et d’obligations persistantes, non de manquements supplémentaires à compter. Ils répondent à trois questions différentes : comment poursuivre le service, quelle permission de marque disparaît et quelles obligations dépassent la durée de l’accréditation.

BTW a déjà consacré un article au choix du registrar repreneur et un autre aux limites opérationnelles d’un fichier placé sous séquestre. Le sujet présent ne rejoue ni la sélection ni la restauration. Il porte sur la qualification publique des éléments qui ont conduit à la décision.

Une ligne de statut par sujet

La page des avis donne déjà un état par affaire. Une table de disposition par élément rendrait le dossier plus résistant aux résumés approximatifs.

Chaque ligne pourrait indiquer l’identifiant du sujet, sa catégorie, la clause exacte, la source publique et sa date d’observation, la correction ou l’information demandée, l’échéance et les prolongations, l’état de la réponse, la disposition à chaque avis, son rôle explicite dans la décision en cours, ainsi que toute correction, contestation, procédure arbitrale ou suspension publique.

Après la résiliation, la ligne nommerait le responsable de l’étape suivante et la date de révision. Un manquement peut être clos, survivre sous forme de dette ou entrer en litige. Une préoccupation peut recevoir une réponse, devenir plus tard un grief formel ou rester une mention historique. Le tableau montrerait ces changements au lieu de laisser le lecteur les reconstituer.

Ce mécanisme ne publierait ni boîtes aux lettres privées, ni noms personnels, ni journaux bruts, ni stratégie juridique. La publicité nécessaire concerne le type de décision et son résultat attribuable.

Le principe tiré des notes de Heng Lu est ici une méthode, non une source de droit : un pouvoir institutionnel à fort effet doit rester relié à son mandat, ses preuves, sa responsabilité et sa voie de recours. Le contrat fonde le pouvoir de l’ICANN. La méthode empêche simplement que la reformulation publique en étende silencieusement la portée.

Sources

  1. ICANN — Avis de résiliation adressé à IPIP INC., 28 août 2026
  2. ICANN — Avis de manquement adressé à IPIP INC., 5 août 2026
  3. ICANN — Avis de manquement, suspension, résiliation et non-renouvellement
  4. ICANN — Registrar Accreditation Agreement et documents connexes
  5. ICANN — Registration Data Policy
  6. ICANN — Profil RDAP des gTLD
  7. ICANN — Programme de séquestre des données des registrars
  8. ICANN — Approche et procédures de conformité contractuelle
  9. ICANN — Mettre fin à une accréditation
  10. ICANN — De-Accredited Registrar Transition Procedure
  11. Heng Lu — Quand le pouvoir du registre se détache de la responsabilité