
Notes sur la Tour d’Ivoire : la méthodologie
Ceci est le post n°2 de mon Notes de la Tour d’Ivoire série. Dans le post n°1, j’ai écrit sur le problème : comment démarre chaque projet de données et d’IA.
Cette fois, le sujet est la méthodologie, et pourquoi « inviter, sortir » est ce qui arrive souvent lorsque nous l’ignorons.
Inviter à entrer, sortir
J’ai souri légèrement lorsqu’un de mes contacts a commenté : «Tu m’as envoyé AI Slop » sous une publication aléatoire qui avait des centaines de likes. La publication, qui contenait une matrice de décision, offrait des conseils sur la plate-forme à utiliser pour des charges de travail de données spécifiques, bien qu’avec des critères discutables. La qualité mise à part, elle avait vraiment l’air géniale.
Mon amusement ne s’est pas arrêté là car j’ai réfléchi à la manière dont l’AIS, c’est-à-dire « AI Slop », devrait désormais être ajouté sous forme de bouton sur tous les réseaux sociaux, à côté du bouton J’aime.
Si des utilisateurs de YouTube lisent ceci, il s’agit d’une idée de fonctionnalité au lieu de questionner les gens, « Est-ce que cela ressemble à une saloperie d’IA ?»
Néanmoins, YouTube a réussi la partie « ressenti », car nous avons tous tendance à prendre des décisions basées sur les émotions, souvent au détriment de la pensée critique.
Pourquoi investirions-nous de l’énergie dans l’empirisme, le rationalisme et le scepticisme alors que nous disposons désormais de l’IA ? Les délais ne sont pas de notre côté, et nous disposons de ce nouvel outil qui nous fournit des résultats, quel que soit l’effet « invite, sortie ».
Mais supposons que vous soyez réellement intéressé par la façon dont la plateforme A se compare à la plateforme B en termes de capacités d’apprentissage automatique (ML), car vous avez remarqué que deux équipes de données dans votre entreprise utilisent des plateformes distinctes pour des cas d’utilisation de ML presque identiques. Votre objectif est donc de dresser un aperçu objectif des deux et de proposer de réduire les coûts de développement en n’en gardant qu’un seul.
Et maintenant ? Comment déterminez-vous si vous devez consolider les charges de travail de ML ?
Sûrement pas en s’appuyant uniquement sur l’IA, mais plutôt sur…
Le chemin de l’enquête
Et vous voilà de retour à l’époque de la Tour d’Ivoire, où on vous enseignait que chaque découverte était couverte par « La méthodologie » :
Le problème → L’hypothèse → Tester l’hypothèse → Les conclusions
De plus, on vous a appris que trouver le problème représente la moitié du travail, et que l’art d’y parvenir consiste à poser de bonnes questions pour le réduire à quelque chose de spécifique et testable.
Par conséquent, vous répondez à la question vague : «Devrions-nous consolider sur une seule plateforme ML ? »et vous continuez à le réécrire jusqu’à ce qu’il devienne quelque chose auquel un test peut répondre :
La plate-forme A gère-t-elle notre pipeline de désabonnement avec une précision comparable et un coût inférieur à celui de la plate-forme B ?
Vous avez désormais défini un sujet, une comparaison et des éléments mesurables, ce qui suffit à transformer une question business en une hypothèse testable.
Mais d’abord, vous faites vos devoirs et rassemblez des informations supplémentaires, telles que le coût actuel de la plate-forme B par tâche, sa précision et la manière dont elle est conçue (par exemple, les données, l’algorithme et les hyperparamètres qu’elle utilise), afin de pouvoir reproduire le pipeline sur la plate-forme A.
Ensuite, avant que les opinions sur votre question ne commencent à affluer, vous déclarez :
Si nous exécutons le même pipeline de désabonnement sur la plate-forme A au lieu de la plate-forme B, en utilisant des données, un algorithme et des hyperparamètres identiques, le coût médian par tâche diminuera d’au moins 15 %, tandis que la précision moyenne restera à moins d’un point de pourcentage de celle de la plate-forme B.
Avec cette formulation « si-alors », vous avez réussi à calmer (au moins certaines) réponses opiniâtres, sachant que la PoC viendra ensuite. Ainsi, pour tester la présomption énoncée, vous concevez et exécutez le PoC, où vous modifiez uniquement la variable indépendante, qui est la plate-forme. Parallèlement, vous figez les variables de contrôle : l’ensemble de données, l’algorithme et les hyperparamètres, et mesurez le coût et la précision, qui sont vos variables dépendantes.
Vous répétez également l’exécution plusieurs fois pour séparer le signal du bruit en collectant plusieurs points de données, en considérant comment une seule exécution peut être faussée par le bruit ambiant (par exemple, le cache), et vous souhaitez éviter ce scénario. Ensuite, vous tenez compte de plus de nuances, par exemple en déclenchant des exécutions à différents moments de la journée (matin, soir ou nuit), pour exposer les deux plates-formes au même mélange de conditions.
Enfin, vous collectez tous les résultats et évaluez les données par rapport à votre hypothèse, ce qui vous mène à l’un de ces trois résultats :
- Résultat 1 : Les données soutiennent votre hypothèse*. Les multiples analyses montrent que la plate-forme A est au moins 15 % moins chère et que la précision reste dans les limites définies. (*Pour information seulement : les données soutiendront, mais ne prouveront pas, votre hypothèse, c’est-à-dire qu’elles vous donneront une raison de la conserver, ce qui, en science, est aussi proche d’un « oui » que possible.)
- Résultat 2 : Les données rejettent votre hypothèse. Les multiples exécutions montrent comment la plate-forme A n’a pas réussi à répondre à l’un ou aux deux critères ; il n’était que 5 % moins cher, ou bien le coût baissait, mais la précision se dégradait au-delà du seuil défini.
- Résultat 3 : Vos courses sont trop bruyantes pour qu’on puisse l’appeler d’une manière ou d’une autre, et la seule réponse est de continuer à tester avant de tirer des conclusions.
Quel que soit le scénario dans lequel vous vous trouvez, vous avez des conclusions : soit vous avez confirmé votre supposition éclairéeappris quelque chose de nouveau ou découvert que vous deviez continuer à tester.
Et pour être clair sur ce court exemple : les deux premières conclusions ne vous donneront pas le feu vert pour consolider deux plateformes. La réalité de l’entreprise (et une évaluation approfondie) est un peu plus complexe que cela, et il y a plus de données (à collecter et à évaluer) affectant les personnes et les processus qu’un PoC à portée unique ne peut en traiter.
Très bien, nous pouvons arrêter avec la méthodologie maintenant, car la plupart d’entre vous lisent probablement les étapes ci-dessus et se demandent…

Qu’est-ce que c’est ? Où est l’IA dans tout ça ?
Je ne peux qu’imaginer à quel point quelque chose de similaire à : « MCP, cadres agents, agents,… » vous passait par la tête en lisant les étapes ci-dessus. Je ne pourrais pas être plus d’accord, toutes ces bonnes choses, et c’est ainsi que vous pourriez accélérer le processus.
Cependant, il suffit de publier les résultats de l’IA à partir d’une invite du type : « Donnez-moi un aperçu de la façon dont Plate-forme A se compare à Plate-forme B pour les charges de travail ML, » est l’endroit où se produit la pente, et « si vous ne faites pas la pratique, votre opinion à ce sujet est très probablement complètement fausse.»
« Si vous ne faites pas la pratique, votre opinion à ce sujet est très probablement complètement fausse. »
La pertinence et l’influence positive ne proviennent pas de jolies publications sur l’IA ou d’infographies de présentation, et elles peuvent nuire aux relations de travail.
Lorsque vous exercez déjà une influence et que vous souhaitez être considéré comme une autorité, il serait plus efficace de partager vos points de vue et vos conclusions issues d’expériences réelles et de votre propre expérience éprouvée.
Au lieu de commencer vos messages »C’est ici que vous devez utiliser la plateforme A plutôt que Plate-forme B pour…», essayez quelque chose de plus concret (si c’est vrai, bien sûr) :
« Quand nous (j’ai) changé le [independent variable] pour voir comment cela affecte le [dependent variable]tout en gardant le [control variables] pareil, notre (le mien) résultats étaient… »
Et puis voyez si le nombre de vos abonnés augmente et faites rapport des résultats.
L’inspiration pour cet article est venue d’un article croate du professeur Mladen Šolić, « Uvod u znanstveni rad » (Introduction à la recherche scientifique, 2005, [LINK]). Je l’ai lu pour la première fois en tant qu’étudiant, et c’est toujours l’une des explications les plus claires sur la façon de mener des recherches scientifiques que j’ai rencontrées.
Merci d’avoir lu.
Si vous avez trouvé cet article utile, n’hésitez pas à le partager avec votre réseau. 👏
Connectez-vous pour plus d’histoires sur Moyen ✍️ et LinkedIn 🖇️.



