IA & Code : la méthode de SAP pour ne pas « brûler des tokens à l’aveugle »

LeMagIT : Avec l’augmentation des prix de l’IA, qu’anticipent de nombreux observateurs, SAP va-t-il facturer ses fonctionnalités IA à ses clients sur la base des tokens qu’ils consomment dans vos applications ?

Philipp Herzig, CTO de SAP : Non. Nous ne sommes pas un revendeur de tokens. Notre modèle est différent. Nous partons de la valeur créée par un cas d’usage.

Prenons la clôture financière. Si nous permettons à un client de la réaliser 50 % plus vite, cette amélioration est quantifiable en euros ou en dollars. La valeur absolue varie évidemment selon la taille de l’entreprise, mais notre principe est le suivant : 80 % de cette valeur économisée revient au client, nous en conservons 20 %.

Et c’est avec cette part que nous devons absorber à la fois nos coûts d’infrastructure et celui des tokens… tout en dégageant une marge.

Et vous y arrivez ?

Philipp Herzig : Nous avons déjà déployé cette approche avec un agent de clôture financière auprès de dix premiers clients. Nous ne sommes peut-être pas encore dans nos cibles financières, mais cela ne m’inquiète pas. En observant le comportement des utilisateurs, on optimise toujours dans un second temps. C’est ce que nous avons fait avec succès dans de nombreux domaines. Donc oui, on y arrive.

« Nous ne sommes pas un revendeur de tokens. Nous partons de la valeur créée par un cas d’usage. »

En tout cas, ce débat sur l’explosion [annoncée] du coût des tokens ne nous prend pas par surprise chez SAP. On peut maîtriser tout cela, mais c’est un vrai travail. Et c’est précisément pourquoi tout le monde ne peut pas le faire.

Plus globalement, nous avions déjà échangé sur ce point, mais les gens commencent à comprendre que faire un logiciel, ce n’est pas juste faire des bouts de codes et les assembler. Il faut aussi une ingénierie solide autour de tout cela.

Justement, comment optimisez-vous vos modèles ? Et comment gérez-vous concrètement le coût des tokens dans le temps ?

Philipp Herzig : Au lancement d’un cas d’usage, nous utilisons souvent un modèle frontier, comme Opus 4.7. Puis avec le temps, on bascule fréquemment vers des modèles beaucoup plus économiques, comme Gemini 2.5 Flash.

Nous ajoutons aussi des couches de pré-traitement pour réduire le volume de tokens en entrée et en sortie. Ces optimisations sont très spécifiques à chaque cas d’usage.

Et quand on dispose de suffisamment de données, on peut aller encore plus loin et se passer complètement des gros modèles. On fine-tune un modèle plus petit, éventuellement open source/open weight, qui tourne en inférence à un coût bien inférieur.

« Nous avons réduit nos coûts de tokens d’un facteur 10 chaque année depuis trois ans. [...] Brûler des tokens à l’aveugle n’est ni une démarche d’ingénierie sérieuse ni une voie durable »

Concrètement, comment cela se traduit-il chez SAP ?

Philipp Herzig : Nous avons réduit nos coûts de tokens d’un facteur 10 chaque année depuis trois ans.

Vous êtes donc un fervent opposant du Tokenmaxxing et de ces classements qui mettent en avant les développeurs qui « brulent » le plus de tokens ?

Philipp Herzig : C’est absurde ! C’est une stratégie pilotée par la peur de rater quelque chose, c’est du FOMO pur.

Mais brûler des tokens à l’aveugle, souvent en utilisant en permanence le modèle le plus puissant disponible, ce n’est ni une démarche d’ingénierie sérieuse ni une voie durable.

Je fais souvent cette comparaison. Vous ne conduisez pas une Lamborghini en ville. Vous pouvez peut-être le faire à l’occasion, mais c’est rarement le choix le plus rapide ou le plus pratique. Et vous brûlez une quantité de carburant considérable pour rien !

Les modèles frontier ont leur place, notamment pour démarrer des cas d’usage. Mais vous devez toujours avoir l’optimisation en tête.

L’IA a-t-elle changé la manière dont SAP développe ses logiciels ?

Philipp Herzig : Complètement. De toute façon, il ne peut pas en être autrement. Si vos concurrents écrivent du code dix fois plus vite, vous n’avez pas le choix : vous devez suivre.

« Si vous continuez à développer “comme avant”, vous n’êtes plus compétitif ; et probablement plus employable. »

Tous nos développeurs utilisent des outils comme Claude Code ou Copilot au quotidien. Cela dit, une fois passée la phase d’adoption, j’insiste, il faut faire un vrai travail d’optimisation et d’ingénierie.

Nous avons par exemple développé des infrastructures qui basculent automatiquement entre différents modèles selon la complexité de la tâche. La formation des équipes est une autre partie du travail.

Car soyons clairs, si aujourd’hui vous n’utilisez pas ces outils et que vous continuez à développer « comme avant », vous n’êtes plus compétitif ; et probablement plus employable.

Ne pensez-vous pas que l’IA va rendre les développeurs, et les votres donc, obsolètes ?

Philipp Herzig, CTO de SAP : Beaucoup de gens ont vu à quelle vitesse ces outils permettaient de produire quelque chose qui, au premier abord, avait l’air super. Donc ils ont cru que les développeurs allaient devenir inutiles.

C’est une illusion.

« Ces modèles d’IA sont des “stagiaires sous stéroïdes” »

J’appelle souvent ces modèles d’IA des « stagiaires sous stéroïdes ». Ils me rappellent ces jeunes diplômés que j’embauchais quand j’étais manager.

Ils étaient pleins d’énergie, ils produisaient une quantité impressionnante de code, mais quand ils soumettaient un pull-request – et que vous l’examiniez – vous réalisiez qu’ils auraient dû utiliser une bibliothèque qui existait déjà, ou qu’ils ont complètement manqué un pattern architectural clé. Le code en lui-même était peut-être très bien écrit, mais il ne s’intégrait pas forcément dans un système plus global.

Personnellement, j’utilise évidemment ces outils. Mais il m’arrive souvent d’interrompre un modèle en cours de travail. En général, c’est ma faute : j’ai mal formulé mes instructions. Un meilleur prompting de ma part aurait permis au modèle de donner directement les bonnes orientations, le bon feed-back pour déboguer, et de générer le code de la bonne manière.

« Une profonde maîtrise technique restera nécessaire encore très longtemps »

Mais encore faut-il être capable de donner ces instructions correctement et de juger le résultat. Si vous ne comprenez pas ce qui est généré, comment pouvez-vous savoir si c’est bon pour votre logiciel ?

Et une fois encore, certains réduisent le développement à l’écriture de lignes de code. Mais ce n’est pas ça. Le développement logiciel est un art. Donc je réponds non à votre question. Une profonde maîtrise technique restera nécessaire encore très longtemps.