CometAPI

Qu’est-ce que CometAPI ?

CometAPI est une plateforme d’agrégation d’API multi-modèles destinée aux développeurs et aux entreprises, qui relie des modèles de texte, d’image, de vidéo et d’audio provenant de différents fournisseurs au moyen d’un seul compte, de clés et d’un système de facturation. Elle vise principalement à résoudre le problème de la dispersion des formats d’interface, des clés, des factures et de la logique de basculement entre les différents modèles.

La page produit indique que CometAPI a été fondée en janvier 2025 par Sonic et s’adresse aux utilisateurs professionnels du monde entier ; les conditions publiques sont soumises à la loi de Hong Kong. La page publique actuelle ne mentionne pas le nom complet de la personne morale chargée de l’exploitation ; lors des achats en entreprise, il convient de confirmer davantage l’entité contractante dans le contrat, la facture et les documents de traitement des données.

Fonction principale

Catalogue et interfaces de modèle unifié

• Appeler les modèles de plusieurs fournisseurs à l’aide d’une seule clé CometAPI, couvrant des tâches telles que les dialogues, le raisonnement, la programmation, la génération et l’analyse d’images, la vidéo, la voix et la musique.
• Le catalogue public des modèles fournit l’identifiant du modèle, le fournisseur, ses capacités, les endpoints disponibles ainsi que des informations de facturation ; les applications peuvent consulter ce catalogue avant de s’exécuter.
• Les flux de travail courants pour du texte, des images, de l’audio et de la vidéo utilisent un format de requête compatible avec OpenAI ; les projets disposant déjà d’un SDK OpenAI n’ont généralement qu’à remplacer l’adresse de base, la clé et l’identifiant du modèle pour commencer les tests de migration.
• Tous les modèles ne prennent pas en charge exactement les mêmes paramètres, entrées ou structures de sortie ; il est nécessaire de consulter la documentation des endpoints du modèle avant de l’intégrer, et on ne peut pas se contenter de remplacer simplement le nom du modèle.

Capacités de texte, d’images, de vidéo et d’audio

Changement de modèle et fallback en cas de panne

• L’application peut passer du modèle principal à un modèle de secours compatible, tout en conservant la même clé et l’adresse d’interface.
• La documentation officielle recommande de ne recourir à un mécanisme de fallback que en cas d’échec de connexion, de délai d’attente, de limitation du débit et d’erreurs temporaires du serveur ; les erreurs de paramètres, les erreurs de clés et les champs non pris en charge doivent être corrigées directement.
• Si vous souhaitez revenir à l’interface de connexion directe avec le fournisseur du modèle, vous devez disposer d’un compte, d’une clé, d’un budget et d’une identifiant de modèle distincts, et les frais liés à la connexion directe seront facturés séparément.
• Lors du passage entre familles de modèles, il faut unifier les champs d’entrée et de sortie, et vérifier les capacités essentielles telles que la mise en appel d’outils, l’aspect visuel, la longueur du contexte et la sortie structurée.

Tâches asynchrones, polling et appels de retour

• Après la création d’une tâche de durée égale à celle d’une vidéo, un identifiant de tâche est retourné ; l’application peut alors interroger régulièrement l’état de la tâche, jusqu’à ce qu’elle réussisse, échoue ou soit annulée.
• L’adresse de rappel ne peut être configurée que si les endpoints sélectionnés la prennent explicitement en charge ; les charges de rappel des différents fournisseurs ne sont pas entièrement uniformes, l’application doit conserver l’événement d’origine et le normaliser elle-même.
• Le polling doit servir de référence d’état final en cas de rappel de perte ; le traitement des rappels doit être idempotent selon l’identifiant de la tâche, afin d’éviter des notifications multiples entraînant des enregistrements redondants.
• Le résultat final peut être retourné via le champ de résultats ou l’endpoint de téléchargement du contenu ; la forme exacte dépend de la page du modèle.

Espace de travail et gestion d’équipe

• Workspace est utilisé pour gérer les membres au sein de l’organisation ; le Owner et l’Admin peuvent inviter ou supprimer des membres, tandis que le Member peut consulter la liste des membres.
• La zone de travail ne détient pas de crédits indépendants ; les membres demandent à utiliser le solde de l’organisation ; seul le propriétaire de l’organisation peut recharger, configurer des recharges automatiques ou échanger des codes de solde.
• L’invitation expire après 24 heures, et lorsqu’un membre est supprimé, les enregistrements des clés API qu’il a créés dans l’espace de travail sont également supprimés.
• L’équipe doit créer des clés distinctes pour l’environnement et les services, en combinant des limites de quota, une rotation et des procédures de départ du personnel, afin qu’aucune personne ne partage la même clé à long terme.

Processus d’accès complet

1. Inscrivez-vous et accédez à la console pour consulter d’abord le répertoire des modèles actuels, les capacités des endpoints et les unités de facturation, puis sélectionnez le modèle principal ainsi que des modèles de secours ayant des capacités similaires.
2. Créez des clés API aux noms clairs, avec des plafonds de quota définis par projet ; copiez-les puis conservez-les dans un système de gestion des clés serveur ou dans des variables d’environnement.
3. Remplacez l’adresse de base de l’interface et la clé dans le client OpenAI existant, ou installez le SDK officiel, puis saisissez l’identifiant exact du modèle dans le répertoire.
4. Effectuer des appels minimaux avec de courts prompts, enregistrer le contenu de la réponse, l’identifiant du modèle, la consommation de tokens, le délai et l’identifiant de la requête, afin de vérifier que le format de la requête est correct.
5. En fonction des flux d’entrée complémentaires liés aux opérations, des résultats structurés, des images ou des flux multimédia asynchrone, ne transmettez pas le même ensemble de paramètres à des modèles non pris en charge.
6. Pour limiter le trafic et gérer les erreurs temporaires, on ajoute un recul exponentiel, des fluctuations aléatoires et une limite de concurrence ; les tentatives de réessai sont interrompues pour les requêtes invalides et les échecs d’authentification.
7. Vérifiez le solde et la consommation dans la console, et définissez des budgets, des quotas de clés ainsi que des seuils de rechargement automatique en fonction des enregistrements réels des appels.
8. Tester le modèle principal, le modèle de secours et les mécanismes de fallback directs avec le fabricant avant mise en ligne, et mettre en place des alertes pour la désactivation du modèle, les changements de prix et les factures anormales.

Développement d’interfaces et de SDK

Les SDK officiels Node.js et TypeScript sont conçus pour être utilisés du côté serveur, et il est clairement indiqué de ne pas placer les clés à long terme dans le code du navigateur, les journaux, les captures d’écran ou des dépôts publics. La version actuelle 0.1.x prend en charge la finalisation des conversations, les Responses et la liste des modèles ; les images, vidéos, audio, le traitement par lots, le fine-tuning ainsi que les méthodes en temps réel ne font pas partie des fonctionnalités par défaut prises en charge par cet SDK.

Prix et mode de facturation

CometAPI utilise un modèle de facturation à l’usage avec des crédits prépayés, sans frais mensuels fixes, sans minimum d’achat ni frais de souscription. Lorsque l’utilisateur recharge son compte, les crédits sont déduits en fonction du nombre réel de tokens, des actifs générés, des segments ou de la durée utilisée ; tant que le compte est actif, le solde acheté ne périt pas.

Méthodes de tarification selon les différents modèles

La page des prix affiche en même temps le prix unitaire instantané des différents modèles ; les prix de mise en ligne, de retrait et ceux du fabricant peuvent varier. Le budget doit être estimé en utilisant le prix d’entrée, le prix de sortie ou le prix unitaire de la tâche actuel pour le même modèle, et corrigé par la facture réelle une fois l’appel terminé.

Rechargement automatique et demandes échouées

• L’utilisateur peut configurer, dans son compte, un rechargement automatique via Stripe lorsque le solde est inférieur à un seuil, et peut modifier ou désactiver ces paramètres à tout moment.
• Les requêtes rejetées en raison de paramètres ou d’authentification par le gateway avant la redirection ne sont pas facturées, tout comme les requêtes pour lesquelles un erreur serveur est renvoyée depuis l’upstream.
• La génération en flux est interrompue une fois le contenu retourné, et le paiement s’effectue généralement en fonction des tokens générés ; les requêtes achevées avec succès mais dont les résultats ne correspondent pas aux attentes subjectives sont facturées intégralement.
• En cas de solde insuffisant ou d’échec de paiement, la plateforme peut suspendre ou restreindre les services ; le système de production ne doit pas dépendre uniquement des recharges automatiques pour assurer sa continuité.

Règles de remboursement

• Les Crédits, les appels API et le temps de calcul déjà utilisés ou consommés ne sont pas remboursables, et le solde n’est ni transférable ni convertible en espèces.
• Les crédits non utilisés peuvent faire l’objet d’une demande écrite, mais l’approbation est à la discrétion de CometAPI et ne constitue pas un droit de remboursement automatique.
• La demande doit indiquer le montant rechargé, la date d’achat, le solde actuel non utilisé et la raison ; la politique de remboursement précise qu’une réponse est généralement donnée dans un délai de 5 jours ouvrés.
• Le remboursement approuvé sera reversé autant que possible par le même moyen de paiement initial ; les frais de traitement qui ne peuvent être remboursés par l’opérateur de paiement, la banque ou un intermédiaire pourraient être déduits.
• Toute réclamation concernant un prélèvement erroné doit être soumise dans un délai de 30 jours à partir de la date du prélèvement ; au-delà de ce délai, le prélèvement pourra être considéré comme accepté.

Adapté aux utilisateurs et aux scénarios

• Les équipes de développement d’applications souhaitent utiliser un ensemble d’interfaces pour comparer et basculer entre plusieurs modèles.
• Équipes de produits nécessitant une sélection dynamique des coûts et des capacités dans les domaines du service client, du contenu, de la recherche, de la programmation ou des systèmes d’agent.
• Équipes techniques créatives qui génèrent en masse des images, des vidéos courtes, des doublages ou de la musique, tout en souhaitant unifier le solde et les factures.
• Départements de R&D d’entreprise qui doivent attribuer des espaces de travail aux membres, partager les solde organisationnels et gérer de manière centralisée les clés.
• Équipes d’infrastructure qui ont besoin d’un fallback multi-modèles ou souhaitent réduire la dépendance à un seul fournisseur de modèles.

Avantages et limites des capacités

• L’unification des clés, des catalogues et des factures permet de réduire les accès redondants, mais la couche d’agrégation ne supprime pas les différences entre les modèles en termes de paramètres, de politiques de contenu, de capacités et de qualité de sortie.
• La plateforme prend en charge le recours interne aux modèles, mais la classification erronée, l’idempotence, les files d’attente, les délais et la connexion directe finale avec le fabricant doivent encore être conçues par l’application elle-même.
• La limite de débit est influencée par le compte, le modèle, le routage et la capacité en amont ; les capacités élevées présentées ne doivent pas remplacer les tests de charge en production ni les engagements contractuels.
• Le nombre de modèles publics et les modèles spécifiques évoluent constamment ; l’environnement de production doit fixer l’identifiant du modèle et surveiller les annonces de retrait.
• La sortie du modèle peut être inexacte, contrevenir aux droits d’auteur ou ne pas être adaptée à l’activité ; l’utilisateur doit néanmoins effectuer une vérification des faits, de la sécurité, des droits d’auteur et de la conformité.
• Il est interdit de revendre, de sous-licencier ou de redistribuer les services sans autorisation écrite ; si une plateforme commerciale souhaite fournir des capacités API à ses clients finaux, elle doit d’abord déterminer la modalité d’autorisation.

Confidentialité, sécurité et conformité

• La politique de confidentialité indique que CometAPI ne collecte, ne stocke ni ne enregistre pas les suggestions, les entrées, les sorties et le contenu des conversations, et ne conserve pas non plus ces éléments dans sa propre base de données.
• La demande est toujours acheminée en temps réel vers le fournisseur du modèle réel pour générer des résultats ; par conséquent, les politiques de traitement des données, de conservation et de contenu de chaque fournisseur en amont doivent être examinées séparément.
• La plateforme collecte des adresses IP limitées, l’heure, la fréquence des requêtes, le navigateur, le dispositif et les historiques d’accès, à des fins de sécurité, de conformité, d’analyse et d’optimisation des services.
• L’inscription à un compte peut collecter un nom d’utilisateur et une adresse e-mail ; lors de la connexion via GitHub ou Google, le nom d’utilisateur et l’adresse e-mail utilisés pour l’authentification sont obtenus avec le consentement de l’utilisateur.
• La plateforme affirme ne pas vendre, louer ou échanger d’informations personnelles, mais peut en divulguer certaines en cas de exigences légales ou réglementaires, et déclare avoir mis en œuvre des mesures techniques et organisationnelles raisonnables sans pouvoir garantir une sécurité absolue.
• L’entreprise indique que le SOC 2 Type II fait partie de son plan d’action en cours, ce qui ne permet pas de conclure que la plateforme a déjà obtenu cette certification.

Recommandations de sécurité pour les clés API

1. Créer des clés distinctes pour le développement, les tests et la production, définir des limites raisonnables, et ne les conserver que dans des variables d’environnement serveur ou dans un système de gestion de clés.
2. Il est interdit d’écrire les clés dans les paquets de navigateur, les clients mobiles, les dépôts de code publics, les journaux, les captures d’écran ou les tickets de support.
3. Le journal ne conserve que les champs d’analyse des pannes tels que l’identifiant du modèle, son état, le délai et l’identifiant de la requête, sans enregistrer les clés ni le texte original inutile de l’utilisateur.
4. Dès la découverte d’une fuite, annuler et renouveler immédiatement la clé, vérifier les utilisations anormales, les recharges automatiques et les droits des membres.

Statut open source et support de la plateforme

Résumé

CometAPI convient aux équipes de développement qui ont besoin d’accéder rapidement à plusieurs modèles, de gérer un solde unifié et de conserver la capacité de basculer entre les modèles. Sa valeur réelle dépend du fait que les modèles ciblés soient stables et accessibles, que les interfaces soient pleinement compatibles, ainsi que de la capacité de l’équipe à gérer les coûts, les clés, les tentatives de réessai et les politiques fournisseurs.

Lors du lancement, il est conseillé d’utiliser d’abord des crédits d’essai pour effectuer les appels minimaux, puis d’utiliser des données réelles pour tester la qualité, les délais et les coûts. Avant de préparer un déploiement en production ou un rechargement important, il convient également de vérifier le cycle de vie du modèle, les niveaux de service entreprise, les parties contractuelles, les conditions de remboursement et les exigences relatives au traitement des données en amont.