Est-il prévu de répondre aux cas d'usages suivants :
avoir des données disponibles à certains partenaires (par exemple entre plusieurs utilisateurs) mais non découvrables par le public (pas disponible dans la recherche, pas possible de demander accès)
avoir un JDD avec un mix de données ouvertes à tous et certaines ressources restreintes
avoir des réutilisations ou discussions partagées uniquement au producteur (partage d'informations ou de données privilégiées)

Non ces cas d'usages ne sont pas prévus.

Par contre je suis d'accord avec @AntoineAugusti la distinction API "externe" vs API "automatique" est complexe a comprendre. La distinction vient de nos mécaniques internes et cela ne devrait pas avoir d'impact sur l’UX.

Complètement d'accord, en ésperant que la seconde version vous semble plus cohérente :)

Désolé @agarrone mais crois que je trouve le pivot sur les réutilisations pas évident :

• le terme d’API comporte une notion de moyen d'accès, finalement un peu au meme niveau qu'un téléchargement de fichier. Pas sur que les utilisateurs pensent a ouvrir l'onglet réutilisation pour y chercher une API
• comment tu gères les API qui ne sont pas liées à un fichier ou un jdd ? Comment référencer une API qui fait de l'écriture par exemple ? Ou une API comme franceConnect ou meme une API de chatbot ?

Désolé @agarrone mais crois que je trouve le pivot sur les réutilisations pas évident :

Pas de soucis merci du retour !

• le terme d’API comporte une notion de moyen d'accès, finalement un peu au meme niveau qu'un téléchargement de fichier. Pas sur que les utilisateurs pensent a ouvrir l'onglet réutilisation pour y chercher une API

Je suis d'accord que c'est pas évident, on s'interroge sur le fait de renommer cet onglet.
Tu le verrais comment toi ?

• comment tu gères les API qui ne sont pas liées à un fichier ou un jdd ? Comment référencer une API qui fait de l'écriture par exemple ? Ou une API comme franceConnect ou meme une API de chatbot ?

En théorie les APIs devraient être associé à un jeu de données y compris restreint à terme.
Pour le type d'APIs que tu évoque c'est pas simple mais je me demande si ces APIs ont leur place sur data.gouv.fr.

Les API sont un service qui peut permettre d'accéder ou pas à des données.

Je pense que pour data.gouv (data) seules des API permettant d'accéder à des données (ouvertes) devraient être répertoriées pour ne pas tout mélanger.

Là aussi il faut distinguer les API qui fournissent un service en plus sur les données ou pas.

Exemple: l'API de géocodage de la BAN fait bien plus que fournir un accès aux données aux données de la BAN. C'est une forme de réutilisation des données avec une valeur ajoutée quasiment plus importante que les données.

Je ne suis pas chaud du tout pour le "tout API", je l'ai souvent exprimé (https://cq94.medium.com/les-api-cest-bien-en-abuser-ca-craint-b5d1c92b32f2), je vais donc me répéter.

Les API posent les problèmes suivants:

• la création de dépendance pour les ré-utilisateurs des données -> si l'API est indispo cela les impacte
• la création d'une charge bien plus importante pour le diffuseur -> il doit avoir une SLA au top pour éviter d'impacter les ré-utilisateurs
• la gestion pour le diffuseur du scaling: on tombe vite dans la fixation de quota, la création de comptes pour les gérer, ou de whitelists, etc... où alors c'est un chèque en blanc sur les besoins de ressources qui seront nécessaires et une SLA de plus en plus difficile à maintenir.

On a malheureusement pas retenu la leçon avec l'API de la BAN ou une version de démo d'un outil de géocodage (addok) est petit à petit devenue un service critique qu'il n'aurait pas dû devenir.

Les API restent pertinentes dans des cas finalement limités :

• accès contrôlé aux données
• données de très grand volume
• données avec une fréquence très élevée de mise à jour

Le diffusion avec des formats opimisés cloud (parquet, cog, flatgeobuf, pmtiles, etc) diffusés en http simple (ou s3) est une alternative intermédiaire à très fort potentiel... mais qui ne semble intéresser personne, malheureusement.