Nos applicatifs tournaient sur AWS depuis plusieurs années. Puis une exigence est arrivée, non négociable : pouvoir les opérer sur un cloud souverain européen. La contrainte n'était pas de quitter AWS mais de ne pas en dépendre, c'est-à-dire de garder une seule base de code applicative, capable de tourner aussi bien sur AWS que sur Scaleway.
Quand le prix du code chute, quel sont les centres de coût du développement logiciel ? Et comment s'adaptent, dès maintenant, un développeur et un manager ?
Avoir un environnement de test, c'est une norme de l'industrie. La vraie question est la suivante : avez-vous un environnement dédié aux tests automatisés ? Parce que tant qu'il ne l'est pas, il est partagé. Et un environnement partagé, c'est un environnement où n'importe qui peut, sans le vouloir, fausser vos résultats.
Une suite de tests au vert. Une fonctionnalité livrée. Et pourtant, dès la mise en production, un utilisateur déclenche en trois clics un bug que personne n'avait vu venir : un export PDF qui explose dès qu'un libellé contient des caractères spéciaux. Le scénario est familier, et c'est exactement là que les tests exploratoires entrent en jeu.
Nos applicatifs tournaient sur AWS depuis plusieurs années. Puis une exigence est arrivée, non négociable : pouvoir les opérer sur un cloud souverain européen. La contrainte n'était pas de quitter AWS mais de ne pas en dépendre, c'est-à-dire de garder une seule base de code applicative, capable de tourner aussi bien sur AWS que sur Scaleway.
Des dossiers domain/, application/, infrastructure/, des interfaces partout, quatre couches d'abstraction pour un service : la forme semble correcte, pourtant le code reste rigide, couplé, impossible à tester sans un mur de @patch. On paye le prix de l'abstraction sans jamais en voir le bénéfice. Dans cet article, on revient sur les raisons profondes de chaque règle, pour savoir quand l'appliquer, quand s'en passer, et reconnaître les fausses bonnes pratiques qui coûtent sans rien rapporter.
Chez Athoria, le testing et la qualité font partie de notre ADN. Alors quand nous avons mis en production AIA, notre assistant IA, une question nous a occupés bien avant le moindre incident : comment s'assurer que nos agents restent pertinents le jour où l'on change de modèle de langage, ou simplement lorsqu'on met à jour notre base de connaissances ? Car une application d'IA générative n'a rien de déterministe, et sa base de connaissances est vivante. Sans mesure, sa qualité peut dériver sans qu'on s'en aperçoivent. Beaucoup d'entreprises butent sur la mise en production à grande échelle pour cette raison précise : la difficulté à évaluer et à fiabiliser l'application. Nous aborderons dans cet article notre retour d'expérience sur ce sujet, applicable à toute application d'IA générative textuelle intégrant un RAG.
Quand le prix du code chute, quel sont les centres de coût du développement logiciel ? Et comment s'adaptent, dès maintenant, un développeur et un manager ?
Avoir un environnement de test, c'est une norme de l'industrie. La vraie question est la suivante : avez-vous un environnement dédié aux tests automatisés ? Parce que tant qu'il ne l'est pas, il est partagé. Et un environnement partagé, c'est un environnement où n'importe qui peut, sans le vouloir, fausser vos résultats.
Une suite de tests au vert. Une fonctionnalité livrée. Et pourtant, dès la mise en production, un utilisateur déclenche en trois clics un bug que personne n'avait vu venir : un export PDF qui explose dès qu'un libellé contient des caractères spéciaux. Le scénario est familier, et c'est exactement là que les tests exploratoires entrent en jeu.
Nouvelle offre
Cloud souverain : vos données chez un hébergeur français, avec Scaleway.
Découvrir l'offre →