Trois semaines de l'agacement au SaaS : comment Claude a écrit 90 % du code d'un service de recherche de billets d'avion

Les meilleurs produits naissent d'une douleur personnelle. La formule est depuis longtemps devenue un cliché des startups, mais il arrive qu'un cas lui rende son sens d'origine. Un développeur russe a transformé en trois semaines son agacement face à la recherche de billets d'avion en un service SaaS à part entière, et le modèle de langage Claude a écrit quatre-vingt-dix pour cent du code.

La tâche de départ semblait banale : trouver des billets pour Bali pour cinq personnes, avec des dates de départ flexibles et une durée de séjour déterminée. Quiconque a tenté quelque chose de similaire connaît la sensation : des agrégateurs comme Aviasales ou Skyscanner fonctionnent très bien quand on voyage seul et qu'on connaît les dates exactes. Mais ajoutez des variables, comme un groupe de voyageurs, une plage de dates flottante et une contrainte de durée, et l'interface se met à patiner.

Il faut passer en revue à la main des dizaines de combinaisons, onglet après onglet. C'est là que le déclic s'est produit chez l'auteur du projet : plutôt que de passer des heures en recherche manuelle, il a décidé d'automatiser le processus.

Le résultat est un bot Telegram capable de vérifier plus de mille combinaisons de trajets par heure et de trouver des options avec jusqu'à cinquante-deux pour cent d'économie par rapport à la recherche standard. L'un des enseignements clés du processus : un billet aller-retour peut revenir quarante pour cent moins cher que la somme de deux allers simples. L'évidence paraît frappante, mais les agrégateurs sont loin de toujours montrer clairement cet écart, surtout sur les trajets complexes avec correspondances.

Le volet technique du projet mérite une attention particulière. L'auteur a délibérément choisi l'approche « tout le code est écrit par l'IA » et a confié l'essentiel du développement à Claude. Selon son estimation, le modèle est venu à bout de quatre-vingt-dix pour cent des tâches, de la logique backend à la configuration DevOps.

Il ne s'agit pas d'une simple génération de code répétitif : l'architecture est complexe et comprend la rétro-ingénierie des API fermées de compagnies aériennes et d'agrégateurs, le contournement de systèmes antibot, et une infrastructure analytique avec des métriques de CTR, de rétention et des entonnoirs de conversion. Trois semaines pour passer de zéro à un produit fonctionnel avec de vrais utilisateurs : il y a quelques années, ce rythme aurait exigé une petite équipe et plusieurs mois de travail.

Il faut toutefois nuancer : ce cas soulève aussi des questions dérangeantes. La rétro-ingénierie des API d'autrui et le contournement de mécanismes de protection sont des pratiques qui flirtent avec les limites de la légalité. La plupart des agrégateurs de billets d'avion interdisent explicitement la collecte automatisée de données dans leurs conditions d'utilisation. Cela ne signifie pas que ces projets n'ont pas le droit d'exister, mais la montée en charge d'un tel service se heurtera inévitablement à des barrières juridiques et techniques. Les entreprises mettent régulièrement à jour leurs protections, et la jurisprudence sur le scraping reste contradictoire.

Un autre aspect est bien plus intéressant : la vitesse à laquelle les modèles de langage permettent à une seule personne de créer des produits d'un niveau autrefois réservé aux équipes. Quand Claude prend en charge la routine de l'écriture de code, le développeur peut se concentrer sur la réflexion produit : que construire exactement, pour qui et comment mesurer le succès. L'auteur souligne qu'il pensait en parallèle au backend, au DevOps, à l'UX et aux métriques business, et que cette capacité à garder toute la vision en tête distingue un projet réussi d'une démonstration technique.

Ce cas s'inscrit dans la tendance montante du « one-person SaaS », où les outils d'IA deviennent un multiplicateur de capacités pour les développeurs indépendants. On voit de plus en plus d'histoires où une personne qui comprend bien un problème et dispose de modèles de langage modernes sort un produit plus vite qu'une équipe d'entreprise ne boucle son cycle de validation. Cela n'élimine pas le besoin d'équipes pour les projets de grande envergure, mais abaisse radicalement le seuil pour tester des hypothèses.

Trois semaines, un développeur, un modèle de langage en coauteur et un service en ligne à la clé. Une formule qui semblait exotique il y a un an devient aujourd'hui la nouvelle norme. La question n'est plus de savoir si l'IA peut aider à écrire du code, mais si le développeur a assez de flair produit pour canaliser cette puissance dans la bonne direction.