Blog sur le développement logiciel et les technologies

Début 2025, un laboratoire appelé DeepSeek a publié des modèles égaux aux capacités de raisonnement de systèmes frontier bien plus coûteux, pour un budget d’entraînement qui ressemblait à une erreur d’arrondi, et le monde de l’IA a collectivement perdu son calme. Un seul mot revenait dans toutes les explications : distillation. Un an plus tard, le sujet est revenu à la une quand Anthropic a signalé que plusieurs laboratoires avaient copié son modèle Claude à l’échelle industrielle, générant plus de 16 millions d’échanges avec Claude via environ 24 000 comptes frauduleux.

Chaque équipe de développement logiciel finit par atteindre un point de rupture où la question de l'amélioration du processus de revue de code devient primordiale. Les fondateurs et les PDG constatent un ralentissement des mises en production, l'apparition de bugs et l'accumulation des plaintes des utilisateurs.

Lorsqu'un utilisateur tape une question complète dans la barre de recherche et n'obtient rien d'utile, il reformule rarement sa requête et réessaie. Il abandonne simplement, et cette friction s'accumule à chaque session et à chaque compte.

La plupart des produits SaaS qui échouent ont été construits correctement. Ils ont résolu le mauvais problème, ou ont résolu le bon problème dans le mauvais ordre, et le code a parfaitement fonctionné tout au long du processus.

La plupart des équipes d'ingénierie qui développent un produit SaaS pensent que leur couche de webhooks est sécurisée dès que la vérification de signature est réussie. Cette croyance est la faille. Les webhooks constituent la plomberie silencieuse derrière les paiements, le provisionnement, les notifications et les intégrations, et ils se trouvent à une URL publiquement accessible qu'un attaquant peut atteindre aussi facilement que vous. Selon le rapport 2026 Data Breach Investigations Report de Verizon, l'implication de tiers est à l'origine de 48% de toutes les violations de données, soit une augmentation de 60% par an. Les webhooks se situent précisément dans cette couture des tiers.

Une attaque par distillation de modèle ne nécessite pas d'intrusion dans vos systèmes, car vous avez divulgué la clé dès l'ouverture de votre API au public. Pour vos concurrents, le moyen le plus économique d'obtenir un modèle similaire au vôtre pourrait être votre propre produit, interrogé des milliers de fois jusqu'à ce qu'une copie, plus modeste, apprenne à répondre de la même manière. Dans vos journaux, cela ressemble à un client actif, mais pour votre entreprise, il s'agit d'une fuite progressive de la capacité d'IA que vous avez développée pendant de longs mois et pour laquelle vous avez investi des sommes considérables.

Si vous exploitez un prototype basé sur Claude, vous devez être attentif au moment où le passage à l'échelle de l'IA devient une nécessité. Pour savoir quand cela se produit, demandez-vous si cette situation vous est familière : vous avez approuvé un prototype interne Claude, et pendant la première semaine, cela ressemblait à de la magie. Votre équipe s'est connectée à l'API d'Anthropic, a rédigé quelques prompts et a regardé l'IA gérer les réponses aux clients, résumer des rapports ou trier des données en quelques secondes. Vous avez perçu le potentiel et immédiatement célébré la victoire.

Le parcours vers une observabilité SaaS optimale commence généralement par l'un de ces deux pièges extrêmes et accidentels. Au départ, la plupart des fondateurs optent pour la solution de facilité. Ils ne suivent absolument rien, déploient des fonctionnalités à une vitesse fulgurante et supposent naïvement que tout va bien jusqu'à ce qu'un utilisateur exaspéré dénonce un bug critique sur les réseaux sociaux. Paniqués, ils basculent brutalement dans l'autre extrême : l'achat d'une plateforme de supervision massive et professionnelle avant même d'atteindre 500 utilisateurs actifs.

La plupart des fondateurs de SaaS échouent non pas parce qu'ils ont construit une mauvaise solution sur le plan technique, mais parce qu'ils ont pris de mauvaises décisions au mauvais moment. Le plus souvent, les erreurs fatales résultent d'une validation insuffisante avant le développement, ou d'un développement excessif avant la vente. Mettre à l'échelle trop tôt est également un problème courant qui peut conduire à l'échec. Autrement dit, le produit lui-même fonctionne souvent bien ; c'est la séquence des étapes qui dysfonctionne.

Claude Code est devenu un levier de productivité sérieux pour les équipes d'ingénierie. Les gains des premières semaines sont généralement évidents. Ce qui l'est moins, c'est ce qui se passe une fois que votre équipe commence à l'utiliser pour des travaux plus longs et plus ambitieux : refactorisations multi-fichiers, audits importants, développements de fonctionnalités de bout en bout. À cette échelle, la qualité de la sortie et le coût cessent de suivre la trajectoire initiale, et les raisons ne sont pas toujours faciles à discerner d'un point de vue de management.