Cinq moteurs musicaux, un seul adaptateur

Un client potentiel m'a récemment demandé de cadrer l'ajout de génération musicale par IA à son produit. Deux générateurs, l'utilisateur choisit un style, une chanson en sort. En surface, c'est une requête POST vers un fournisseur et un bouton de lecture. J'ai fini par cartographier l'essentiel du marché pour répondre à ses questions, et le paysage s'est révélé suffisamment intéressant pour que je construise l'intégration cinq fois, face à cinq moteurs différents, afin de montrer ce que cela exige vraiment. Le résultat est une petite preuve de concept fonctionnelle : une couche d'adaptateurs, cinq fournisseurs, une CLI, et une interface studio dockerisée où changer de moteur revient à choisir dans un menu déroulant.

Voici ce que cet exercice enseigne.

L'appel d'API est la partie facile

La génération musicale, ce n'est pas requête puis réponse. Un morceau met de 30 secondes à quelques minutes à être rendu, donc la vraie ingénierie se trouve tout autour de l'appel : un modèle de jobs, des webhooks ou du polling avec backoff, des retries qui tolèrent un endpoint de statut capricieux, des timeouts qui échouent bruyamment, et du stockage. Surtout du stockage. Les URL des fournisseurs expirent : l'un supprime les fichiers après 14 jours, un autre après une semaine, un troisième tue le lien au bout de 24 heures. Si votre produit stocke l'URL du fournisseur au lieu de l'audio, la bibliothèque de vos utilisateurs pourrit en silence. La première règle quand on construit sur ces API : télécharger le fichier dès qu'un job aboutit et le placer dans un stockage qui vous appartient.

Cinq fournisseurs, cinq formes différentes

Les cinq moteurs que j'ai intégrés, et la forme que chacun s'est révélé avoir :

• Suno, en revente. Suno n'a pas d'API publique officielle, donc le son préféré du marché arrive par des revendeurs non officiels. Celui que j'ai intégré exige une URL de callback même si vous faites du polling, répond au polling en camelCase et aux webhooks en snake_case pour les mêmes données, et renvoie deux variations de morceau par requête.
• MiniMax. Officiellement pris en charge et, étonnamment, synchrone : la réponse HTTP de l'appel de création contient déjà le morceau terminé. L'intégration la plus simple qui soit, et le lien renvoyé meurt sous 24 heures.
• ACE-Step. Un modèle à poids ouverts sous licence Apache, servi via une API à file d'attente. Le mot du schéma d'authentification est littéralement « Key » au lieu de « Bearer », et il n'y a pas de champ de prompt : il veut des tags de style et des paroles, où « [inst] » signifie instrumental.
• Treblo. Une API officielle dont l'endpoint de statut renvoie une simple chaîne JSON nue, dont le format de sortie par défaut est ogg, et qui exige une attribution visible dans tout produit destiné aux utilisateurs. Elle a aussi abandonné le nom Sonauto et déplacé ses endpoints en plein milieu de mes recherches, comme si l'univers tenait à souligner le propos de cet article.
• Eleven Music. Synchrone comme MiniMax, mais le corps de la réponse contient les octets audio bruts. Pas d'identifiant de job, pas d'URL, rien à interroger. Attrapez les octets ou perdez-les.

Cinq fournisseurs, cinq schémas d'authentification, trois modèles asynchrones, deux conventions de casse dans les réponses, et un changement de marque, le tout en une seule semaine. Rien de tout cela n'a sa place près du code de votre produit.

L'adaptateur est la décision produit

Le remède est vieux, ennuyeux, et il fonctionne : placer chaque moteur derrière un contrat unique. Le mien tient en deux fonctions, créer un job et rafraîchir un job, toutes deux renvoyant la même forme normalisée. L'orchestration, le stockage, l'interface et la facturation ne savent jamais quel moteur a tourné. Ajouter un fournisseur, c'est un fichier ; changer de fournisseur, c'est une chaîne de configuration ; et quand un revendeur disparaît du jour au lendemain, change de nom, ou qu'une API officielle finit par apparaître, vous reconfigurez au lieu de réécrire.

Cette dernière phrase n'a rien d'hypothétique. Les wrappers non officiels reposent sur un terrain juridiquement contesté tant que les procès des labels contre les créateurs de modèles suivent leur cours, et le wrapper que vous intégrez aujourd'hui n'existera peut-être plus sous le même nom au trimestre prochain. Je l'ai vu arriver en plein projet. L'adaptateur n'est pas une coquetterie d'architecture, c'est la police d'assurance.

Ce que les avocats vous demanderont

Les questions qui décident réellement du moteur que vous pouvez utiliser n'ont rien à voir avec la qualité sonore :

• Droits commerciaux. Un fournisseur vous cède la propriété des sorties dans ses conditions. Un autre n'accorde l'usage commercial qu'à travers des textes marketing, sans licence contractuelle derrière. Un troisième reste entièrement muet pour les clients API. Ce sont trois positions de risque très différentes qui paraissent pourtant identiques dans une démo de fonctionnalité.
• Filigranes. Un moteur se réserve le droit d'apposer un filigrane à sa discrétion. Un autre propose des content credentials en opt-in. Le modèle à poids ouverts n'en a aucun. Si la marque de votre client ne peut pas porter de filigrane, c'est un filtre, pas une préférence.
• Attribution. Un moteur exige un crédit « Powered by » visible dans votre interface. C'est une contrainte de design produit cachée dans une page de conditions.
• Indemnisation. Aucun des cinq ne vous défendra si un morceau généré s'approche trop de la chanson de quelqu'un. Ce risque reste chez vous, ce qui en pratique signifie que vos conditions d'utilisation le transfèrent à vos utilisateurs. Cela vaut une heure d'avocat avant le lancement, pas après.

Je garde tout cela dans un tableau comparatif dans le dépôt, juste à côté du code, parce que ce tableau change l'adaptateur que vous activez bien plus souvent que n'importe quel benchmark.

Écoutez

Un prompt, directement à travers l'adaptateur : une chanson sur un mari et sa femme à Banff, marchant au bord du lac Louise, la neige sur les sommets, retombant amoureux. Ce qui suit est exactement ce qui en est ressorti, une seule génération, sans trier parmi plusieurs.

Treblo (Melodia v3), 2 minutes 50 :

Une note sur ces deux générations : le prompt demandait une voix masculine chaleureuse, et Treblo a fait chanter la première prise par une femme. La deuxième, ci-dessous, plaçait la voix masculine dans les tout premiers mots du prompt, et c'est encore une femme qui l'a chantée. Ce moteur n'expose aucun paramètre de genre vocal (Suno via kie.ai a un vrai drapeau vocalGender), ce qui transforme une exigence d'un mot en loterie. La leçon vaut les crédits dépensés : quand un réglage compte pour votre produit, choisissez un moteur qui l'expose comme paramètre, pas comme un espoir dans le prompt.

Cette section grandit à mesure que je fais passer le même prompt par les autres moteurs ; leurs versions s'afficheront ici côte à côte. Chaque sortie est générée par IA, et les droits qui s'y rattachent relèvent des conditions du fournisseur.

Voyez-le tourner

Ce qui se trouve derrière cet article est réel et tourne : une édition CLI Node de l'adaptateur, sans aucune dépendance, et un studio dockerisé FastAPI plus React où les moteurs et leurs modèles sont des menus déroulants, un moteur factice démontre le pipeline complet sans la moindre clé API, et chaque morceau terminé atterrit dans le stockage local dès qu'il aboutit, parce qu'à ce stade vous savez pourquoi. Je le garde comme un plan de travail privé qui fonctionne, et l'intérêt d'un plan, c'est que le suivant, le vôtre, se construit bien plus vite.

Si vous cadrez un projet de génération musicale, ou n'importe quelle fonctionnalité générative qui tourne sur le modèle de quelqu'un d'autre, la forme de la réponse est la même : le fournisseur est un plugin, le contrat vous appartient, et les parties ennuyeuses, la file d'attente, le stockage, les conditions, sont là où vit réellement le projet. C'est aussi exactement le genre de chantier que j'aide les équipes à livrer.