Les produits sur lesquels je travaille comportent de plus en plus deux volets. Le premier est celui que les gens utilisent : une interface Next.js, une API Node.js, l’authentification et les paiements. Le second concerne les modèles : inférence, embeddings, audio et traitement de données. Le premier parle TypeScript, le second Python. Maîtriser les deux ne consiste pas à collectionner les langages, mais à assumer leur jonction — précisément là où beaucoup de produits IA se cassent.
Bonne nouvelle : les deux écosystèmes se ressemblent davantage qu’on ne le pense. À Zod correspond Pydantic ; à tsc, mypy et pyright ; à ESLint et Prettier, Ruff ; à npm et pnpm, uv et Poetry. FastAPI joue auprès d’Express et NestJS et génère même OpenAPI à partir de modèles typés. J’applique la même discipline des deux côtés : typage strict, formateur qui ne prête pas à débat, dépendances verrouillées et tests dans la CI.
Le contrat entre les deux est le fichier le plus important du système. Je le définis une fois, puis génère le reste : les modèles Pydantic de FastAPI produisent un schéma OpenAPI, qui sert à générer le client TypeScript et ses types. Renommez un champ en Python et le build Next.js échoue avant qu’un utilisateur ne voie un undefined. Pour l’asynchrone, le contrat est un payload de tâche avec un schéma à chaque extrémité, pas un JSON libre interprété différemment par chaque côté.
La répartition des responsabilités reste stricte. TypeScript gère l’identité, les permissions, l’argent et l’UI. Python gère le modèle, et rien d’autre : il reçoit une tâche, effectue le travail lourd — une voix StyleTTS2, un lot d’embeddings ou l’analyse d’un document — puis renvoie un résultat. Le service Python ne communique jamais avec le navigateur et ne décide jamais des autorisations. Les appels rapides passent par HTTP, les lents par une file d’attente, avec délais d’expiration, nouvelles tentatives et idempotence des deux côtés.
Les différences comptent aussi et il faut les respecter. Python se prête au prototypage dans un notebook, mais un notebook n’est pas la production : le code abouti doit rejoindre un module accompagné de tests. La concurrence Python n’est pas la boucle d’événements de Node : l’inférence intensive en CPU doit tourner dans des processus workers ou sur un service GPU, pas dans un gestionnaire de requête asynchrone. Les unités de déploiement diffèrent également — image Node légère ou image Python avec CUDA et poids du modèle —, donc l’échelle, le cache et le coût aussi.
Pour le client, l’intérêt d’un seul ingénieur des deux côtés est simple : pas de couche de traduction entre « la personne IA » et « la personne web », et pas d’API dont chacun rejette la faute sur l’autre. Si votre modèle fonctionne déjà dans un notebook mais que votre application web ne sait pas encore s’en servir, envoyez-moi les deux. Je proposerai le contrat entre eux et la première version que je mettrais en production.
Donnez à votre prochain produit quelqu’un qui reste.
Prêt à commencer ? Écrivez-moi — je peux démarrer immédiatement et rester dans la durée. Des collaborations à long terme, pas une passation après deux semaines. Discutons de votre projet, de vos exigences et de la meilleure façon d’avancer.