Une application web qui analyse vos parties d'échecs et vous les commente comme le ferait un professeur, ça paraît presque magique côté utilisateur. On clique, on importe une partie, et quelques secondes plus tard un texte pédagogique explique où on s'est trompé. Sauf que derrière cette simplicité apparente se cache une mécanique complète, du navigateur jusqu'au serveur. Nous en savons quelque chose, nous avons conçu ce type d'outil de bout en bout et mis en ligne un vrai service (shatar.fr). Petit retour d'expérience sur ce que veut vraiment dire "développer une application web full-stack avec de l'IA", de la première ligne de code au déploiement en production.
Tout commence par un vrai besoin, pas par une techno
On a tendance à croire qu'un projet web démarre par le choix d'un framework ou d'un langage. En réalité, il démarre presque toujours par un besoin concret, quelque chose qui coince dans la vraie vie. Dans notre cas, l'envie de départ était simple, presque familiale, apprendre les échecs à partir d'un livre de référence sans passer son temps à replacer les pièces à la main.
De ce petit besoin est né un choix structurant, partir sur du sur-mesure plutôt que sur un outil tout fait. Un template ou une solution clé en main aurait imposé ses limites au bout de deux semaines. Le développement d'une application web sur mesure, lui, permet de coller exactement à l'usage, quitte à ne coder que ce qui sert vraiment. C'est souvent ça, le vrai retour sur investissement d'un projet réalisé sur mesure, on ne paie pas pour des fonctionnalités qu'on n'utilisera jamais.
Front, back, base de données, l'anatomie d'une application full-stack
Le terme "full-stack" revient partout, mais il mérite qu'on s'y arrête. Une application web moderne, c'est en réalité l'assemblage de plusieurs couches qui doivent dialoguer sans accroc.
- Le front-end, la partie visible dans le navigateur, ce que l'utilisateur voit et manipule. Ici, une interface construite avec React et TypeScript, avec un vrai échiquier interactif.
- Le back-end, le moteur côté serveur, invisible mais central, qui reçoit les demandes, applique la logique métier et sécurise les échanges. Chez nous, du Node.js avec Express, en TypeScript là aussi.
- La base de données, la mémoire de l'application, qui range les comptes, les parties enregistrées, les préférences. Une base légère et rapide a suffi pour ce projet.
L'intérêt d'un même langage de bout en bout (le TypeScript, ici, du navigateur au serveur) n'est pas anecdotique. Ça réduit les erreurs, ça facilite la maintenance, et ça permet à une petite équipe d'avancer vite sans se perdre entre plusieurs univers techniques.
L'intelligence artificielle au bon endroit, ni partout ni nulle part
C'est le coeur du sujet, et c'est là qu'on voit passer beaucoup d'idées reçues. Mettre de l'IA dans une application, ce n'est pas saupoudrer un chatbot sur une page. C'est décider, très précisément, ce que la machine doit calculer elle-même et ce qu'on délègue à un modèle de langage.
Dans notre application, deux briques cohabitent. D'un côté, un moteur d'échecs qui tourne directement dans le navigateur de l'utilisateur pour évaluer les positions, sans rien envoyer sur le serveur. De l'autre, un modèle d'IA générative (l'API Claude d'Anthropic) qui transforme cette évaluation, froide et chiffrée, en un commentaire pédagogique rédigé en bon français, avec un résumé personnalisé de la partie et les thèmes à travailler.
La règle qu'on s'impose est toujours la même, on utilise l'IA là où elle apporte une valeur que le code classique ne sait pas produire, ici, expliquer avec des mots. Pour tout le reste, un algorithme déterministe est plus fiable, plus rapide et gratuit.
Penser multi-utilisateurs dès le premier jour
Un prototype qui marche sur son propre ordinateur, c'est encourageant, mais ce n'est pas un service. Le vrai basculement, c'est le moment où plusieurs personnes se connectent, chacune avec son compte et ses données.
Ça change tout dans la conception. Il faut gérer l'authentification de façon sérieuse, avec des mots de passe jamais stockés en clair (on les chiffre) et des jetons de connexion sécurisés qui évitent le vol de session. Il faut aussi distinguer les rôles, un administrateur ne voit pas la même chose qu'un simple membre. Et il faut cloisonner les données, chacun chez soi.
À noter, cette architecture multi-comptes, une fois posée, ouvre la porte à un modèle économique. C'est exactement ce qui permet, plus tard, de proposer des offres différentes selon les utilisateurs, du gratuit au payant.
Maîtriser le coût de l'IA, le nerf de la guerre
Voilà un point que beaucoup découvrent trop tard. Une fonctionnalité d'IA générative a un coût réel, facturé à l'usage par le fournisseur du modèle. Si on laisse chaque utilisateur lancer autant d'analyses qu'il veut, la facture peut grimper très vite, et un service gratuit devient intenable.
Nous avons donc travaillé la question sous deux angles. D'abord, l'efficacité technique, plutôt que de multiplier les allers-retours avec le modèle, on lui envoie tout le contexte de la partie en un seul appel bien construit, ce qui réduit à la fois la latence et le coût. Ensuite, des quotas par utilisateur, avec des paliers, un visiteur gratuit dispose d'un certain nombre d'analyses, un membre premium en a davantage.
C'est une compétence à part entière, concevoir une application qui utilise l'IA sans se ruiner. Un projet bien pensé garde la main sur sa consommation, au lieu de la subir.
Du localhost au serveur, l'étape qu'on sous-estime toujours
Il y a un gouffre entre "ça marche sur ma machine" et "c'est en ligne, ça tourne tout seul, jour et nuit". Le déploiement en production est souvent la partie la moins glamour d'un projet, et pourtant c'est elle qui décide si le service existe vraiment.
Concrètement, il a fallu installer l'application sur un serveur dédié (un VPS), la faire tourner en permanence grâce à un gestionnaire de processus qui la relance automatiquement en cas de pépin, configurer le serveur web pour servir les pages et sécuriser les échanges en HTTPS avec un certificat. Sans oublier une règle d'or, les secrets (clés d'API, clés de sécurité) ne vivent que sur le serveur, jamais dans le code partagé. Une mise à jour mal gérée qui écraserait ces secrets, et c'est le service entier qui tombe.
Cette maîtrise de la chaîne complète, du code jusqu'à la mise en ligne et à la supervision, fait partie intégrante du métier. Livrer, ce n'est pas seulement coder, c'est aussi exploiter.
Changer de nom sans sacrifier son référencement
Dernier chapitre, et pas des moindres pour qui se soucie de sa visibilité. En cours de route, le service a changé d'adresse pour prendre son propre nom de domaine. Une opération banale en apparence, mais qui peut ruiner des mois de référencement naturel si on la bâcle.
La bonne pratique, ce sont les redirections 301, des redirections dites permanentes qui indiquent aux moteurs de recherche que l'adresse a changé pour de bon. Bien faites, elles transfèrent la réputation de l'ancienne adresse vers la nouvelle, et l'internaute comme Google retombent toujours sur leurs pieds. C'est un réflexe SEO élémentaire, mais on ne compte plus les sites qui ont perdu leur trafic pour l'avoir oublié.
À noter, penser au référencement dès la conception d'une application, et pas seulement après coup, c'est ce qui distingue un projet mené par des développeurs qui comprennent aussi les enjeux de visibilité.
Ce qu'un projet comme celui-ci dit de notre façon de travailler
Au fond, cette application d'échecs est un bon condensé de ce que réclame le développement d'une application web moderne, un besoin clair au départ, une architecture full-stack solide, de l'intelligence artificielle placée avec discernement, une gestion sérieuse des utilisateurs et des coûts, et un déploiement propre qui pense aussi au référencement.
C'est cette capacité à tenir toute la chaîne, de la première esquisse jusqu'au service en ligne qui tourne tout seul, que nous mettons au service de nos clients. Que votre projet tourne autour de l'IA, de la donnée ou d'un métier très spécifique, la démarche reste la même, comprendre le besoin réel, puis construire l'outil sur mesure qui y répond, sans surcouche inutile. Et si vous avez une idée d'application qui traîne dans un coin, elle mérite peut-être elle aussi de passer du prototype à la production.
Questions fréquentes
Le développement débute par un besoin concret, pas par le choix d'une technologie.
Une application full-stack comprend le front-end, le back-end et une base de données qui interagissent ensemble.
L'IA doit être utilisée là où elle apporte une réelle valeur, comme expliquer des concepts, et non de manière superficielle.
Cela permet de gérer l'authentification et de cloisonner les données, ouvrant la voie à des modèles économiques variés.
Il faut installer l'application sur un serveur dédié, configurer la sécurité et gérer les secrets correctement.
