D'une seule consigne à trois variantes d'approvisionnement, en moins de dix minutes.
L'API REST et le SDK Python de Sympheny sont entièrement documentés, de sorte qu'un assistant IA ou un agent de codage peut construire un projet, préparer des variantes de scénario et lancer une optimisation. Ce qui en sort reste inchangé : le même moteur MILP déterministe résout le modèle, qu'il ait été assemblé par une personne ou par un agent.
Un assistant prépare le modèle. Sympheny le résout.
Une seule consigne, trois variantes d'approvisionnement — chaudière gaz, pompe à chaleur avec solaire en toiture, et réseau de chaleur — préparées via l'API documentée. Clip sans son ; chaque étape est légendée à l'écran.
Les détails et le guide complet dans notre documentation →Cinq étapes, du cahier des charges écrit à trois scénarios prêts à optimiser.
Le clip déroule une préparation réelle : un cahier des charges rédigé en langage courant, le script que l'assistant en tire, les hypothèses qu'il signale avant l'exécution, et les trois scénarios qui en résultent.
« Ajoutez après l'étape 1 une nouvelle étape qui liste tous les projets… » — et le parcours guidé en a une.
L'IA vous aide à construire l'interface. Sympheny optimise de façon déterministe, comme toujours.
Une light app est une petite interface ciblée, construite sur Sympheny — un parcours guidé taillé pour l'étude que votre équipe mène réellement, plutôt que la plateforme entière. C'est dans le Light App Editor que vous la construisez et que vous la modifiez.
Le clip en montre une en cours de modification. Une consigne écrite ajoute une étape à un parcours guidé en quatre étapes déjà déployé, les étapes suivantes sont renumérotées, et le nouvel écran est en ligne deux secondes plus tard. L'étape ajoutée n'est pas une maquette : elle appelle GET /projects sur le backend Sympheny et affiche ce qui revient — propriétaire, statut, dernière mise à jour — pour chaque projet du compte.
Un parcours guidé de quatre étapes déjà en service en gagne une cinquième à partir d'une seule consigne écrite, déployée en deux secondes et alimentée en direct par le backend Sympheny. Clip sans son ; chaque étape est légendée à l'écran. Il montre une light app existante que l'on étend, et non une light app créée depuis zéro.
Parlons de l'IA pour votre propre light app →Tout ce dont un agent a besoin est déjà documenté.
Deux des trois sont disponibles dès aujourd'hui : l'API REST et le SDK Python sont entièrement documentés et pilotables maintenant. Le serveur MCP, qui permet à un assistant de se connecter sans aucun raccordement de votre côté, arrivera dans les prochaines semaines.
API REST
Chaque endpoint est documenté publiquement, avec authentification JWT, schémas de requête et de réponse, et un API Explorer dans le navigateur. Projets, analyses, scénarios, étapes, hubs, technologies et exécutions du solveur sont tous accessibles.
Référence de l'API REST →SDK Python
sympheny-toolbox, le client officiel, requiert Python 3.11 ou plus récent et s'installe avec pip. Il expose chaque endpoint documenté sous forme de méthode typée avec validation Pydantic, propose des clients synchrones et asynchrones équivalents, et gère pour vous la connexion, la mise en cache et le rafraîchissement des jetons. Des guides concrets couvrent le lancement d'une exécution du solveur et le téléchargement des résultats.
Guide du SDK Python →Serveur MCP
Un serveur Model Context Protocol distant, pour qu'un assistant puisse appeler Sympheny via une connexion standard plutôt qu'en HTTP écrit à la main. La configuration client pour Claude Code, Claude Desktop, ChatGPT et Gemini CLI est documentée avant le lancement, et l'endpoint commencera à répondre à la mise en service du serveur, dans les prochaines semaines. D'ici là, l'API REST et le SDK remplissent le même rôle — c'est ce qu'utilise la démonstration ci-dessus.
Configuration MCP, documentée avant le lancement →La documentation est écrite pour être lue par les machines autant que par les personnes.
docs.sympheny.com publie llms.txt, un index compact de la documentation dans l'ordre de navigation avec une description d'une ligne par page, et llms-full.txt, l'ensemble concaténé dans l'ordre de lecture. Tous deux suivent la convention llms.txt.
En pratique, vous pouvez donner une seule URL à un assistant et il a la plateforme en contexte — endpoints, schémas, structure du modèle et exemples concrets — au lieu de parcourir le site ou de deviner la forme d'une API.
Les parties du travail qui valent la peine d'être automatisées.
Travailler avec des assistants et des agents IA.
Puis-je utiliser Sympheny avec un assistant ou un agent IA ?
Oui. Sympheny publie une API REST et un SDK Python, tous deux entièrement documentés, de sorte qu'un assistant ou un agent de codage peut créer des scénarios, lancer des optimisations et en relire les résultats. Un serveur MCP arrivera dans les prochaines semaines. La configuration est documentée sur docs.sympheny.com. Rien n'est connecté par défaut — c'est vous qui décidez d'y recourir ou non.
Puis-je modifier une light app avec un assistant IA ?
Oui. Le Light App Editor reçoit une consigne en langage courant et modifie la light app — dans le clip ci-dessus, il ajoute une étape au parcours guidé qui liste tous les projets du compte, adossée à un véritable appel d'API et déployée en deux secondes. Ce qu'il montre, c'est la modification d'une light app qui existe déjà ; en créer une depuis zéro demande davantage de travail. Dans les deux cas, l'optimisation qui se trouve derrière reste inchangée : le même moteur MILP déterministe résout le modèle.
Si je connecte un assistant, où vont mes données ?
Vers le fournisseur que vous connectez. Si vous pointez un assistant vers Sympheny, les données de scénario qu'il envoie et reçoit passent par ce fournisseur dans le cadre de votre accord avec lui, non du nôtre. Sympheny ne choisit pas le fournisseur à votre place et n'intègre aucun modèle tiers dans son propre pipeline de calcul.
Connecter un assistant change-t-il mes résultats ?
Non. Un assistant peut construire ou modifier un scénario, mais l'optimisation s'exécute toujours sur le même moteur MILP déterministe. Un scénario assemblé par un assistant et le même scénario assemblé à la main produisent les mêmes résultats.
Note : Un assistant peut préparer le modèle. Il ne le résout jamais.
Faut-il être développeur pour utiliser cela ?
Pour l'API et le SDK, oui — ou il faut quelqu'un dans l'équipe qui le soit. Faire écrire le script par l'assistant abaisse considérablement la barrière, mais il faut toujours quelqu'un pour l'exécuter et lire ce qu'il a fait. C'est le serveur MCP qui supprime cette étape, et il arrivera dans les prochaines semaines. D'ici là, c'est un flux de travail pour les équipes disposant d'une certaine capacité de scripting ; tous les autres travaillent dans l'application web, où tourne la même optimisation.
Moins de dix minutes, est-ce réaliste ?
Pour la préparation montrée, oui : un projet à trois variantes avec la demande tirée de la base de données, la spécification de l'API à disposition de l'assistant et quelqu'un qui sait ce qu'il veut modéliser. Une première tentative prend plus de temps, et l'optimisation vient s'y ajouter. C'est une affirmation sur la préparation des scénarios, pas sur la production d'un concept énergétique abouti.
Quand le serveur MCP sera-t-il lancé ?
Dans les prochaines semaines. La configuration client pour Claude Code, Claude Desktop, ChatGPT et Gemini CLI est déjà documentée, et l'endpoint commencera à répondre à la mise en service du serveur. Tout ce que montre la démonstration ci-dessus fonctionne dès aujourd'hui sans lui, via l'API REST et le SDK. Si vous souhaitez être informé de l'arrivée de MCP, signalez-le lors d'un appel de démonstration ou écrivez-nous.
Envie de l'essayer sur un projet à vous ?
Démarrez un essai gratuit et pilotez-le via l'API, ou réservez une démo et nous parcourrons ensemble la préparation sur un projet qui ressemble au vôtre.