
Mettre un modèle de langage en production : tout ce qui change
Non-déterminisme, évaluation, coût variable, pannes silencieuses, repli entre fournisseurs, gestion des prompts : le passage en production d'une fonctionnalité IA, poste par poste.
Thème
35 articles sur ce thème, écrits par les équipes qui construisent les applications dont ils parlent.

Non-déterminisme, évaluation, coût variable, pannes silencieuses, repli entre fournisseurs, gestion des prompts : le passage en production d'une fonctionnalité IA, poste par poste.

Comment choisir un parc de test réaliste, ce que les simulateurs ne montrent pas, et les réglages qui trouvent le plus de défauts.

Les quatre contrôles à passer sur ses données avant tout projet d'IA, et pourquoi le troisième est celui qui fait dérailler les projets.

Les quatre défauts récurrents du code généré, dans l'ordre où il faut les chercher, et la règle d'attribution qui rend la revue tenable.

Les trois indicateurs qui annoncent un dépassement plusieurs semaines à l'avance, et comment traiter les demandes ajoutées en cours de projet.

Reprendre un historique tenu sous Excel : les pièges du fichier « propre », les règles implicites, et une méthode en quatre passes.

Une méthode ordonnée pour traiter un bug qui n'existe qu'en production, et les pièges qui font perdre le plus de temps.

Comment structurer une feuille de route par horizons, ce qu'on y met à chaque niveau, et comment la faire vivre sans la renier.

Pourquoi la reprise de données fait dérailler les projets de remplacement, et la méthode que nous appliquons pour la maîtriser.

Pourquoi une bonne application peut être rejetée, et les cinq leviers qui font réellement basculer les usages.

Ce qui distingue un tableau de bord consulté chaque semaine d'un tableau de bord abandonné au bout d'un mois.

La méthode que j'applique pour prendre en main une application héritée, jour par jour, et les pièges de la première semaine.

Le format de demande que j'utilise, et les quatre formulations qui produisent à coup sûr un développement inutile.

La liste de contrôle que nous appliquons avant chaque mise en production, et les deux erreurs les plus fréquentes sur les applications métier.

La méthode que j'applique quand le commercial, la finance et la production annoncent trois chiffres différents pour la même chose.

Comment répartir un budget de tests limité pour obtenir le maximum de protection, et les tests qui ne servent à rien.

La méthode que j'utilise pour trancher un backlog quand chaque service défend sa demande comme vitale.

Notre méthode d'audit avant de reprendre l'exploitation d'une application existante, et les cinq signaux qui font refuser un dossier.

Pourquoi la recette échoue presque toujours pour les mêmes raisons, et comment la préparer pour qu'elle trouve ce qu'elle doit trouver.

Le parcours réel de publication sur les deux magasins, les motifs de refus les plus fréquents et les délais à prévoir dans un planning.

Pourquoi découper par couches techniques est un piège, et comment tailler des tranches verticales qui se livrent en quelques jours.

Comment définir le périmètre d'une première version, et les trois contresens qui transforment un MVP en produit inutilisable.

La grille de lecture d'un tech lead en revue de code, et les cinq commentaires qui n'ont rien à y faire.

Le découpage réel d'un projet d'application web métier après l'IA, phase par phase, et les trois facteurs qui font vraiment déraper les délais.

Ce que j'ai appris en recrutant et en faisant progresser des développeurs, y compris les erreurs que j'ai répétées.

Le détail de notre chaîne de production augmentée par l'IA : ce qu'elle accélère réellement, ce qu'elle ne touche pas, et pourquoi.

La méthode et les seuils que j'utilise pour retirer une fonctionnalité, et comment le faire sans braquer les quelques personnes qui s'en servent.

L'organisation minimale des environnements et de la chaîne de déploiement, et pourquoi le délai de mise en production est le meilleur indicateur de santé d'un projet.

Pourquoi l'appel d'offres classique fonctionne mal sur un projet applicatif, et quel format lui substituer.

Le déroulé précis de nos ateliers de cadrage, qui doit y participer, et les trois moments où ils déraillent.

Une méthode concrète pour rendre la dette technique visible aux décideurs et la traiter en continu plutôt qu'en crise.

La grille que je conseille à mes prospects pour comparer des prestataires de développement, y compris quand ils ne nous choisissent pas.

Le déroulé d'un premier rendez-vous, ce que nous demandons, ce que vous devez en attendre, et pourquoi nous ne présentons pas nos références.

La méthode de migration progressive que nous appliquons, étape par étape, et les trois conditions sans lesquelles elle échoue.

Ce qu'il faut mettre — et surtout ne pas mettre — dans un cahier des charges applicatif, du point de vue de celui qui les lit toute la journée.
Ces articles décrivent notre façon de travailler. Si le sujet vous concerne, le premier échange sert à qualifier, pas à vendre.