D'une consigne à trois variantes d'approvisionnement, en moins de dix minutes.
L'API REST et le SDK Python de Sympheny sont entièrement documentés : un assistant IA ou un agent de codage peut donc créer un projet, préparer des variantes de scénario et lancer une optimisation. Ce qui en ressort ne change pas : c'est le même moteur MILP déterministe qui 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 consigne, trois variantes d'approvisionnement — chaudière à gaz, pompe à chaleur avec solaire en toiture, et chauffage urbain — préparées via l'API documentée. Séquence muette ; chaque étape est sous-titrée à l'écran.
Les détails et le guide complet dans notre documentation →Cinq étapes, d'un énoncé rédigé à trois scénarios prêts à optimiser.
La séquence déroule une préparation réelle : un énoncé rédigé en langage courant, le script que l'assistant en tire, les hypothèses qu'il signale avant de lancer, 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 par-dessus Sympheny — un parcours guidé calqué sur 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.
La séquence en montre une en cours de modification. Une consigne rédigée 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é en quatre étapes déjà déployé en gagne une cinquième à partir d'une seule consigne rédigée, déployée en deux secondes et alimentée en direct par le backend Sympheny. Séquence muette ; chaque étape est sous-titrée à l'écran. Elle montre une light app existante que l'on étend, et non une light app construite à partir de rien.
Échanger avec nous sur 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 immédiatement. Le serveur MCP, qui permet à un assistant de se connecter sans aucun raccordement de votre côté, arrivera dans les prochaines semaines.
REST API
Chaque endpoint est documenté publiquement, avec authentification JWT, schémas de requête et de réponse et un API Explorer utilisable dans le navigateur. Projets, analyses, scénarios, étapes, hubs, technologies et calculs de 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é comme une méthode typée validée par Pydantic, propose des clients synchrones et asynchrones équivalents, et gère pour vous la connexion, la mise en cache et le renouvellement des tokens. Des guides détaillés couvrent l'exécution d'un calcul de 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 appelle 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 autant par les machines que par les humains.
docs.sympheny.com met à disposition 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. Les deux suivent la convention llms.txt.
En pratique, il suffit de donner une seule URL à un assistant pour qu'il ait la plateforme en contexte — endpoints, schémas, structure du modèle et exemples détaillés — au lieu de parcourir le site ou de deviner la forme d'une API.
Les parties du travail qui valent 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 met à disposition dès aujourd'hui une API REST et un SDK Python : un assistant ou un agent de codage peut ainsi créer des scénarios, lancer des optimisations et en récupérer les résultats. Un serveur MCP est en développement et arrivera dans les prochaines semaines. La mise en place est documentée sur docs.sympheny.com. Rien n'est connecté par défaut — c'est vous qui décidez d'y recourir.
Puis-je modifier une light app avec un assistant IA ?
Oui. Le Light App Editor prend une consigne en langage courant et modifie la light app — la séquence ci-dessus 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'elle montre, c'est la modification d'une light app qui existe déjà ; en construire une à partir de rien est un travail plus long. Dans les deux cas, l'optimisation qui la sous-tend ne change pas : c'est le même moteur MILP déterministe qui résout le modèle.
Si je connecte un assistant, où vont mes données ?
Chez le fournisseur que vous connectez. Si vous branchez un assistant sur Sympheny, les données de scénario qu'il envoie et reçoit transitent par ce fournisseur dans le cadre de votre contrat avec lui, et 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.
Le fait de connecter un assistant modifie-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 donnent 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 tout 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 le niveau requis, mais il faut toujours quelqu'un pour le lancer et relire ce qu'il a fait. C'est le serveur MCP qui supprime cette étape, et il arrivera dans les prochaines semaines. D'ici là, ce flux de travail s'adresse aux équipes ayant un minimum de capacité de scripting ; tous les autres travaillent dans l'application web, où s'exécute la même optimisation.
Moins de dix minutes, est-ce réaliste ?
Pour la préparation montrée ici, oui : un projet à trois variantes avec une demande reprise dans 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. Un premier essai prend plus de temps, et l'optimisation s'ajoute à cette durée. 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 prévenu de l'arrivée de MCP, signalez-le lors d'une démo ou écrivez-nous.
Envie de l'essayer sur un de vos projets ?
Démarrez un essai gratuit et pilotez la plateforme via l'API, ou réservez une démo : nous parcourrons la préparation sur un projet qui ressemble au vôtre.