Trois semaines, de la frustration au SaaS : comment Claude a écrit 90 % du code d’un service de recherche de billets d’avion

Les Meilleurs Produits Naissent de la Douleur Personnelle. Cette phrase est devenue depuis longtemps un cliché des startups, mais la réalité présente parfois des cas qui restaurent son sens original. Un développeur russe a passé trois semaines à transformer la frustration liée aux recherches de vols en un service SaaS entièrement développé, le modèle de langage Claude écrivant quatre-vingt-dix pour cent du code.

Le Problème Original Semblait Banal La tâche initiale était directe : trouver des billets pour Bali pour cinq personnes avec des dates de départ flexibles et une durée de voyage fixe. Quiconque a tenté quelque chose de similaire connaît la sensation : les agrégateurs comme Aviasales ou Skyscanner fonctionnent magnifiquement quand vous voyagez seul et que vous connaissez les dates exactes. Mais ajoutez des variables—un groupe de voyageurs, une plage de dates flottante, une exigence de durée—et l'interface commence à défaillir.

Vous finissez par parcourir manuellement des dizaines de combinaisons, ouvrant onglet après onglet. C'est à ce moment que le déclic s'est produit pour l'auteur : au lieu de dépenser des heures à des recherches manuelles, il a décidé d'automatiser le processus.

Le résultat est un bot Telegram capable de vérifier plus de mille combinaisons de routes par heure et de trouver des options avec des économies allant jusqu'à cinquante-deux pour cent par rapport à la recherche standard. Un aperçu clé découvert au cours du processus : les billets aller-retour peuvent être quarante pour cent moins chers que la somme de deux billets aller simple. Cela semble évident, mais les agrégateurs ne montrent rarement cette différence clairement, surtout avec des itinéraires complexes impliquant des correspondances.

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

Ce n'est pas seulement la génération de code modèle : il s'agit d'une architecture complexe incluant l'ingénierie inverse d'API fermées des compagnies aériennes et des agrégateurs, le contournement des systèmes anti-bot et la construction d'une infrastructure analytique avec des métriques de CTR, de rétention et d'entonnoirs de conversion. Trois semaines de zéro à un produit fonctionnel avec de vrais utilisateurs—un rythme qui il y a seulement quelques années aurait nécessité une petite équipe et des mois de travail.

La Zone Grise Juridique Cela dit, le cas soulève des questions inconfortables. L'ingénierie inverse d'API tierces et le contournement des mécanismes de protection est une pratique qui oscille au bord de la légalité. La plupart des agrégateurs d'aviation interdisent explicitement la collecte automatisée de données dans leurs conditions d'utilisation. Cela ne signifie pas que de tels projets ne doivent pas exister, mais la mise à l'échelle d'un tel service affrontera inévitablement des barrières juridiques et techniques. Les entreprises mettent régulièrement à jour leurs défenses, et la jurisprudence sur le web scraping reste contradictoire.

L'Aspect Plus Intéressant Beaucoup plus intéressant ici est un autre aspect—la vitesse à laquelle les modèles de langage permettent à un développeur solitaire de créer des produits auparavant accessibles uniquement aux équipes. Quand Claude se charge de la routine de l'écriture de code, le développeur peut se concentrer sur la réflexion produit : quoi exactement construire, pour qui, et comment mesurer le succès. L'auteur souligne qu'il a simultanément pensé au backend, DevOps, UX et aux métriques commerciales—et c'est précisément cette capacité à garder la vue d'ensemble à l'esprit qui distingue un projet réussi d'une démonstration technique.

La Tendance des SaaS à Une Personne Ce cas s'inscrit dans l'élan croissant du « one-person SaaS », où les outils d'IA deviennent un multiplicateur de possibilités pour les développeurs individuels. Nous voyons de plus en plus d'histoires où une seule personne avec une compréhension claire du problème et un accès aux modèles de langage modernes lance un produit plus rapidement qu'une équipe d'entreprise ne termine un cycle d'approbation. Cela n'élimine pas le besoin d'équipes sur les projets à grande échelle, mais réduit radicalement la barrière à l'entrée pour tester les hypothèses.

Trois semaines, un développeur, un modèle de langage comme coauteur, et un service en direct comme résultat. Une formule qui semblait exotique il y a un an devient la nouvelle norme aujourd'hui. La question n'est plus de savoir si l'IA peut aider à écrire du code, mais si le développeur a l'intuition produit pour diriger ce pouvoir dans la bonne direction.