Comment on se tient à jour sur l’IA, sans courir après chaque annonce

Être « expert IA » en 2026 ne veut pas dire tout savoir. Ça veut dire savoir, à un instant donné, ce qui a changé pour les produits qu’on construit, et ce qui n’a pas changé. Pour ça, on a une routine simple, tenue à plusieurs, et nourrie par nos missions plutôt que par les réseaux sociaux.

1. Trier : peu de sources, mais les bonnes

On suit d’abord les sources primaires : les notes de version et la documentation des fournisseurs de modèles, les articles de recherche qui accompagnent une sortie, et les textes officiels pour la réglementation (le Journal officiel de l’Union européenne pour l’AI Act, les lignes directrices de la Commission, les publications de la CNIL).

Le reste, on le lit avec une question en tête : est-ce que ça change quelque chose pour un écran, un coût ou un risque chez nos clients ? Une démo spectaculaire qui ne répond à aucune des trois passe au second plan.

2. Tester : sur un vrai cas, pas sur une démo

Une nouveauté qui semble utile est testée sur un cas concret, souvent tiré de nos projets internes : résumer un historique client, lire une facture, classer des messages. On compare avec ce qu’on utilisait avant, sur les mêmes données, et on note trois choses :

• la qualité : est-ce que le résultat est meilleur, et sur quels cas il se trompe ;
• le coût et la vitesse : ce que ça donnerait à l’échelle d’un produit en production ;
• les contraintes : où partent les données, ce que le fournisseur garde, ce que ça implique pour l’AI Act.

Ces essais sont courts, quelques heures en général. Leur intérêt est d’être comparables d’une fois sur l’autre.

3. Partager : ce que chacun voit en mission

La veille la plus utile ne vient pas des annonces, mais du terrain. Chaque membre du noyau travaille sur des produits différents : ce qu’un développeur découvre en intégrant un modèle chez un client, ou ce qu’une designer observe pendant un test utilisateur, est partagé avec les autres. On garde une trace écrite des enseignements, pour que le collectif ne réapprenne pas deux fois la même chose.

Les rencontres du collectif (le KaptiEvent, le hackathon, l’atelier de Tokyo) servent aussi à ça : prendre du recul ensemble sur ce qui a changé.

4. Décider : ce qui entre dans nos méthodes

Un test concluant ne suffit pas. Une pratique entre dans nos missions quand elle a fait ses preuves sur plusieurs cas, et quand on sait expliquer ses limites à un client. C’est ainsi que sont nées nos règles d’interface pour les fonctionnalités IA, détaillées dans un autre article : montrer le doute là où il est, relier chaque proposition à sa source, laisser le dernier mot à l’humain.

À l’inverse, on retire aussi des pratiques. Quand un nouvel outil rend une étape inutile, on la supprime de nos offres plutôt que de la facturer par habitude.

La réglementation, suivie comme une fonctionnalité

L’AI Act et l’European Accessibility Act sont traités comme des sujets produit, pas seulement juridiques. Chaque évolution du calendrier ou des lignes directrices est relue sous l’angle des écrans : qu’est-ce qu’il faut afficher, à quel moment, et comment le rendre accessible. Nos lectures sont publiées ici, avec leur date, pour qu’on sache toujours à quelle version du texte elles se rapportent.

Questions fréquentes

Comment choisissez-vous un modèle d’IA pour un client ?

On compare plusieurs modèles sur un échantillon de ses données, sur trois critères : la qualité des réponses, le coût à l’échelle, et les contraintes de confidentialité et d’hébergement.

Vos recommandations sont-elles à jour de l’AI Act ?

On suit les textes officiels et les lignes directrices de la Commission, et nos articles indiquent toujours leur date. Pour un cas précis, on recommande aussi l’avis d’un juriste.