Héberger le modèle ou l’appeler : ce qui décide vraiment

Un directeur technique à Blida présente deux colonnes à son conseil. À gauche, l’abonnement mensuel chez un fournisseur étranger. À droite, l’amortissement d’une machine. La colonne de droite gagne, le conseil approuve, et la machine passe onze mois de l’année à ne rien faire pendant que quelqu’un la surveille.

Les deux chiffres étaient exacts. Ce qui manquait est ce qui décide réellement entre les deux, et ce n’est ni le prix du million de jetons ni le prix du matériel : c’est le taux d’occupation. Cet article donne les lignes de chaque côté, la formule qui les met en face, et le relevé qui la remplit avec vos chiffres.

Il ne traite pas du droit — ce que la loi permet d’envoyer où est une décision antérieure, et elle peut à elle seule fermer la colonne de gauche. Il suppose cette question déjà tranchée et pose la suivante : à volume donné, quelle architecture coûte le moins, et à partir de quand cela s’inverse. Un projet d’intelligence artificielle se décide dans cet ordre.

La première ligne est l’appel lui-même, facturé au volume de texte traité. C’est celle que tout le monde compare, et c’est souvent la plus petite des trois sur un usage professionnel réel.

La deuxième est tout ce qui accompagne l’appel et qui n’est pas le modèle : l’hébergement de votre propre couche, la base qui stocke vos contenus, l’outil de mesure, l’environnement de test. Un assistant utile n’est pas un appel, c’est un système autour d’un appel, et ce système tourne quelque part.

La troisième est le coût administratif de payer, et c’est celle qui n’apparaît dans aucun devis parce qu’aucun fournisseur ne l’encaisse. Elle se compte en démarches par an plutôt qu’en pourcentage, ce qui a une conséquence contre-intuitive : elle pousse à payer plus cher et moins souvent.

Additionner ces trois lignes est le seul moyen d’avoir une colonne de gauche honnête. Une comparaison qui ne retient que la première compare un abonnement à une infrastructure, ce qui n’a pas de sens dans un tableau à deux colonnes.

Deux entreprises traitant le même nombre de requêtes par mois n’ont pas la même réponse si l’une les reçoit étalées et l’autre concentrées sur trois heures. La machine se dimensionne sur la pointe et se paie sur le mois entier ; l’interface se paie sur le total et ignore la forme.

C’est ce qui rend la question « combien d’appels par mois » insuffisante à elle seule. La bonne question est double : combien au total, et quelle proportion du temps la machine serait-elle réellement occupée. Une occupation de dix pour cent signifie que neuf dixièmes de la dépense fixe achètent de la disponibilité, ce qui est parfois exactement ce qu’on veut acheter, et il faut alors le dire ainsi.

Le cas où la machine gagne franchement est reconnaissable : un volume élevé, régulier, et prévisible sur douze mois. Le cas où elle perd franchement l’est aussi : un usage en dents de scie, saisonnier, ou dont personne ne sait dire s’il existera encore au printemps.

Entre les deux, il y a une zone large où les deux colonnes se valent, et où la décision se prend sur autre chose : le droit, la confidentialité, la disponibilité des compétences. C’est une bonne nouvelle, parce que ces critères-là se discutent mieux qu’un écart de quelques pourcents.

Avec une interface, un incident chez le fournisseur est subi et il est aussi partagé : il est signalé, documenté, et il finit. Avec une machine, un incident est le vôtre, et la question n’est pas de savoir s’il arrivera mais qui le traitera.

Cette ligne se chiffre de la seule façon honnête disponible : en écrivant le nom de la personne qui se lève. Si ce nom est le même pour toutes les astreintes de l’entreprise, la colonne de droite vient d’ajouter une charge à quelqu’un qui en a déjà, et cela s’appelle un point unique de défaillance plutôt qu’une économie.

Il faut y ajouter ce qui se perd quand cette personne part. Une machine installée par quelqu’un qui n’a rien documenté est une machine que le suivant n’ose pas mettre à jour, et une machine qu’on n’ose pas mettre à jour devient un problème de sécurité au bout de quelques mois.

La contrepartie honnête existe et mérite d’être dite : une machine chez vous ne disparaît pas parce qu’un compte a été fermé, et ce qui se perd vraiment dans le cloud n’est pas le serveur mais le droit d’y entrer. Les deux colonnes ont chacune leur mode de défaillance ; aucune n’en est exempte.

Nous instrumentons le relevé ci-dessus, nous établissons les deux colonnes avec vos chiffres, et nous écrivons le seuil avec la date et le taux qui ont servi à le calculer. Nous concevons aussi le système avec la frontière d’appel à un seul endroit, ce qui rend le choix réversible plus tard sans reconstruction.

Nous mesurons la qualité avant le coût lorsque la colonne de droite est envisagée sérieusement : trente cas réels, le modèle hébergeable contre celui de l’interface, et le résultat mis devant vous avant qu’une machine soit commandée. C’est une demi-journée, et elle a annulé plus de projets de machine qu’elle n’en a confirmés.

Nous ne recommandons pas un hébergement local pour des raisons de souveraineté que nous ne pourrions pas tenir. Une machine dans vos murs ne rend pas votre traitement conforme, ne remplace pas un registre, et ne dispense d’aucune obligation — elle supprime une question et une seule, celle du transfert.

Et nous ne vendons pas la machine. Nous n’avons aucune marge sur le matériel, ce qui est la seule raison pour laquelle notre calcul vaut quelque chose : un prestataire qui gagne sur la colonne de droite ne devrait pas être celui qui compare les deux colonnes, et si nous en tirions un revenu, vous auriez raison de faire refaire le calcul ailleurs.