Qui écrit

Je m’appelle Bastien Quelen, je suis DSI de l’ESIEA, une école d’ingénieurs du numérique. Mon terrain est donc celui de l’enseignement supérieur.

Avant ça, j’ai travaillé chez Feedbooks, une plateforme française de distribution de livres numériques, où j’ai fini CTO : tout le développement et toute l’infrastructure, à deux avec le cofondateur.

C’est à peu près le contraire d’une DSI. Là-bas : pas de parc utilisateur à administrer mais une production à tenir en ligne, des arbitrages à la semaine plutôt qu’à l’exercice budgétaire, et des lecteurs qui pouvaient aller voir ailleurs d’un clic. Ici : un parc, des usages captifs, des cycles longs et des contraintes que personne ne choisit. Un même cas d’usage de l’IA ne se juge pas de la même façon dans ces deux mondes, et c’est une partie de ce que j’essaie de rendre lisible.

Pour donner l’échelle de ce dont je parle : 2 000 étudiants et 200 personnels, répartis sur deux campus principaux et deux sites plus petits, avec une équipe SI de moins de dix personnes.

Ce n’est pas un détail de politesse, c’est la contrainte qui décide de tout le reste. À ce ratio — quelques milliers d’utilisateurs, quatre sites, une équipe qui tient autour d’une table — le temps d’entretien disponible est proche de zéro : un cas d’usage qui réclame une surveillance hebdomadaire, un réétalonnage à chaque changement de modèle ou un contrôle humain sur chaque sortie ne passe pas, quelle que soit sa valeur théorique. Avec une équipe de trente, vous conclurez autrement — autant que vous sachiez d’où je parle pour savoir si mes verdicts vous concernent.

Pourquoi « Hugin »

Dans les récits nordiques, Odin envoie deux corbeaux parcourir le monde : Hugin, la pensée, et Munin, la mémoire. Chaque soir ils reviennent lui raconter ce qu’ils ont vu.

C’est à peu près le contrat de ce blog. Je ne prescris pas, je rapporte : quels cas d’usage de l’IA sont réellement en service dans une DSI, ce qu’ils ont changé, ce qu’ils ont coûté, et lesquels ont fini par être débranchés.

Ce qu’on trouve ici

Un cas d’usage par article, traité de bout en bout plutôt qu’en survol. Le périmètre est celui d’une DSI, pas celui d’un laboratoire :

  • Support et exploitation — tri et qualification des tickets, recherche dans les bases de connaissance, aide au diagnostic.
  • Sécurité — détection d’anomalies, revue de journaux, qualification d’alertes.
  • Données — classification, extraction depuis des documents, réconciliation.
  • Développement et projets — assistance au code, rédaction de spécifications et de cahiers des charges, recette.
  • Fonctions internes — achats, contrats, reporting, rédaction.

Chaque article répond aux mêmes questions : quel geste métier change, que se passe-t-il quand le modèle se trompe, où sont les données et qui peut les voir, combien ça coûte en régime établi. Et un verdict : gardé, mitigé, abandonné.

Trois règles d’écriture

  1. Un cas réel, pas une tendance. Un article part d’un usage en service ou arrêté, jamais d’une annonce d’éditeur.
  2. Les coûts font partie du résultat. Un usage qui fonctionne techniquement et rate économiquement est un échec. L’inférence, l’intégration et l’entretien sont chiffrés au même titre que le gain.
  3. Les abandons sont publiés. Ce sont les articles les plus utiles, et les plus rares ailleurs.

Ce que ce blog n’est pas

  • Aucun contenu sponsorisé, aucune tribune d’éditeur. Si un outil est nommé, c’est parce qu’il a été utilisé, et je n’ai aucun intérêt à sa vente.
  • Aucune donnée de mon employeur. Les cas sont décrits à un niveau d’abstraction qui ne divulgue ni volumétrie sensible, ni architecture interne, ni identité de tiers. Les chiffres publiés sont ceux que je peux publier.
  • Ce n’est pas une position officielle. J’écris à titre personnel : ce blog n’est pas un canal de communication de l’ESIEA et mes propos ne l’engagent pas.
  • Aucun traceur, aucun cookie, aucune régie. Rien à accepter en arrivant.

Comment ces articles sont écrits

Oui, l’IA me sert d’aide rédactionnelle, et il serait incohérent de tenir un blog sur ses cas d’usage en m’interdisant précisément celui-là.

Concrètement, elle intervient sur la forme : dégrossir un plan, reformuler un paragraphe qui ne tombe pas juste, relire l’orthographe et la syntaxe, parfois signaler un angle que je n’avais pas vu. Ce qui ne passe pas par elle : le choix des cas, les chiffres, les verdicts, et la décision de publier.

La règle que je m’applique tient en une phrase : je ne publie rien que je ne serais pas capable de défendre en réunion. Tout ce qui est affirmé ici a été vérifié par moi — y compris, et surtout, ce qu’une machine a suggéré. Sur un blog qui juge des cas d’usage de l’IA, cette ligne compte autant que les verdicts.

Sous le capot

Site statique Hugo, thème PaperMod, auto-hébergé : un conteneur nommé saga — la déesse du récit — derrière un reverse proxy Caddy, publié par intégration continue à chaque git push. Pas de base de données, pas de CMS, environ 400 Ko servis.

Me joindre

Les corrections et les contre-exemples sont particulièrement bienvenus : si un cas d’usage a donné chez vous un résultat opposé au mien, c’est exactement l’information qui manque.