Euh donc le premier discours liminaire hier était de tuer tous les leaders d’opinion. Euh donc j’espère que vous ne me verrez pas comme un leader d’opinion, mais au moins j’ai survécu jeudi. Euh mais je veux essentiellement partager ce que d’autres leaders d’opinion ont fait et qui s’est avéré très efficace au cours des 70 dernières années et je crois que cela fonctionnera très bien à travers l’IA euh je ne dirai pas salut, mais à travers l’ère de l’IA.

Euh donc j’ai pas mal de matériel et je sais qu’il est très très difficile de rester alerte pendant une heure. Euh je suis reconnaissant que ce soit la première session de la journée, donc ça vous donne la possibilité de tuer le reste de votre journée. Mais j’espère que je pourrai vous garder éveillés jusqu’à la fin de ce travail parce que les choses les plus intéressantes sont un peu trop évidentes. Le moins intéressant concerne mon passé. Euh donc j’étais vraiment un nerd de l’informatique au début de ma vie. J’ai étudié les mathématiques. Euh et puis j’ai étudié l’informatique et euh mon mon travail pour ce qui est maintenant appelé Master en informatique était de désassembler un système d’exploitation appelé CPM fonctionnant sur Apple II. Et c’était vraiment génial de partir du code machine et de reconstruire le code qui avait été écrit sans savoir s’il était correct ou non. Mais finalement, environ 20 ans plus tard, ils ont publié le code source de CPM. Donc je dois encore vérifier un par un. Mais de toute façon, c’est euh je dis ça ici parce que les gens de l’informatique, normalement, je cache cette partie de ma vie. Et et puis euh plus tard dans ma carrière, je suis devenu DSI pour DFC en France. J’étais aussi euh DSI à Paris de Europcar International, la compagnie de location de voitures. la partie différente du groupe Volkswagen où je travaillais là-bas. Et euh plus tard je suis devenu DSI d’une entreprise de logistique appelée H Logistics basée à Paris et après cela, je suis devenu DSI de Toyota Europe et finalement je suis allé au Japon. Euh et à ma grande surprise car je ne suis plus DSI. La semaine dernière j’ai reçu euh j’ai reçu une sorte de prix d’honneur que je n’attendais pas du tout. Et j’essayais de dire que je ne fais pas que de l’informatique et puis euh et puis j’ai eu cette euh cette intronisation au CIO Hall of Fame. Donc j’ai eu deux récompenses au début et à la fin de ma carrière de DSI. Bref, c’est euh trop de service à la personne et pas intéressant pour vous. Donc euh j’étais au cours des 20 dernières années, euh de 2005 à 2020. Euh j’ai dirigé l’informatique de Toyota en Europe, basé à Bruxelles, qui est aussi ma ville natale. Euh et puis j’ai en fait quitté euh Toyota Europe complètement et j’ai commencé au Japon en tant qu’employé local au Japon pendant les trois dernières années et demie de ma carrière. Euh où j’étais conseiller principal auprès du responsable de la stratégie globale pour une entreprise appelée Toyota Systems Corporation à Nagoya, Japon. C’est donc le regroupement de l’informatique de Toyota Motor Corporation et de trois entreprises informatiques qu’ils avaient déjà. C’est donc 3 000 employés et 9 000 sous-traitants. Environ 12 000 personnes en informatique et euh et ils travaillaient essentiellement pour le Japon. Donc un de mes rôles était d’établir une stratégie globale pour eux. Donc vous les verrez davantage se développer en dehors du Japon. Euh et puis en 2023, j’avais 65 ans, j’ai décidé de je n’ai pas décidé. C’était l’âge normal de prendre ma retraite. Même si au Japon, ils voulaient me garder 10 ans de plus, mais pour différentes raisons, y compris le fait que je suis devenu grand-père en Belgique, j’ai décidé de revenir en Belgique. Mais je m’ennuyais un peu d’être à la retraite. Alors j’ai été à la retraite pendant trois mois et puis euh nous avons créé une entreprise euh avec ma femme qui se cache quelque part. Oui, au fond. Euh et le nom de l’entreprise est Hakoba. Donc pour ceux qui connaissent le Japon et qui ont un enfant au Japon, Hakoba est une série au Japon. Mais si vous l’écrivez avec des caractères chinois, c’est tableau blanc. Et ces deux caractères sont le nom chinois de ma femme et c’est mon nom chinois. C’est l’histoire de ce nom.

Mais même ainsi, à partir de l’année suivante, nous avons commencé à travailler avec un nom de marque qui est Lean Institute Belgium parce qu’il existe un réseau mondial d’instituts Lean qui a été fondé par Womack et Jones qui sont les premiers à avoir écrit un livre sur le Lean euh en 1990, The Machine That Changed the World. Et donc l’un d’eux a commencé aux États-Unis, un autre au Royaume-Uni, et il y a eu le Brésil et ainsi de suite. Et donc nous sommes le numéro 28. Il y a aussi l’IF en France que la plupart d’entre vous connaissent encore. Euh donc nous sommes une petite entreprise sœur de l’IF si vous voulez le voir comme ça. Euh donc l’entreprise, c’est ma femme et moi. Et parfois nous travaillons avec quelques personnes externes. Euh mais euh il y a beaucoup à faire pour deux personnes, donc nous espérons vraiment que euh Atlantic AI fera une grande partie du travail des gens que nous aurions euh embauchés autrement. Euh et donc ce que nous faisons, c’est du coaching exécutif lean, de la formation lean et nous vendons même des livres lean à des gens qui n’achètent plus de livres de nos jours. Donc il y en a quelques-uns parmi vous qui achètent des livres, continuez s’il vous plaît parce que ce n’est pas le meilleur moyen de gagner de l’argent de vendre des livres. Oui, je dis un mot sur notre vie au Japon parce que parfois les gens ne sont pas du tout intéressés par ma présentation, mais ils sont très intéressés par notre vie au Japon. Alors je mets toujours ces deux ces deux diapositives au début. Donc nous étions j’ai de la chance et de la malchance en même temps que nous sommes arrivés le premier jour du COVID. Euh nous avons pris le dernier avion d’Europe pour le Japon et nous sommes arrivés le 18 mars 2020. Et euh et donc le Japon était fermé au monde extérieur. Nous avons donc eu le Japon pendant deux ans pour nous sans aucun touriste. Nous avons donc pu voir le Japon sans touristes et c’est fabuleux. Nous sommes donc allés dans 47 préfectures au Japon. Nous sommes donc allés dans les 47 préfectures. Pas pendant les heures de travail, parfois mais pas trop, mais essentiellement pendant les week-ends et les vacances. Puis à partir de la troisième année, nous avons commencé à voyager en Corée, aux Philippines, à Taiwan, etc. lorsque les routes ont été rouvertes. Euh nous euh nous sommes allés dans des endroits très intéressants comme euh à Hokkaido, nous avons pu voir un ours, pas de trop près en fait. Nous avons eu la chance de gravir le Mont Fuji le jour de mes 65 ans, juste quatre jours avant de rentrer en Europe. Euh je ne le referai plus jamais, mais je l’ai fait. Euh nous avions une maison qui ressemblait plus à une maison américaine qu’à une maison japonaise. Et euh nous avons fait euh une randonnée dans euh dans une île au sud du Japon appelée Yakushima, où l’on va voir un arbre qui a 7 000 ans. Et il faut environ 10 heures pour faire l’aller-retour pour la préparation du Mont Fuji. Nous sommes allés à Okinawa, et nous avons même assisté aux Jeux olympiques de Tokyo, euh où nous avions un drapeau belge parce que non, il n’y avait pas de spectateurs. Donc la seule chose que nous pouvions voir, c’était le cyclisme. Et comme vous le savez, il y a des Belges, je pense en cyclisme, donc nous y étions. D’accord. Euh oui, désolé. Et et à droite se trouve le Google Cloud des photos que nous avons prises partout au Japon.

D’accord. N’essayez pas de désolé. Euh oui. Donc ma vie professionnelle au Japon euh est euh était très intéressante car à cette époque il n’y avait presque pas d’étrangers. Donc une des grandes faiblesses du Japon est qu’ils ont beaucoup de mal à étudier l’anglais. Bien sûr, les anglophones ont aussi beaucoup de mal à apprendre le japonais, mais c’est moins un problème pour eux dans le monde d’aujourd’hui. Donc j’ai donné des cours d’anglais. Euh et j’ai aussi donné des formations aux managers que j’ai appelées fit for Global pour aider les managers à pouvoir discuter lors de réunions mondiales car les Japonais auraient tendance à ne pas parler du tout lorsqu’ils ne sont pas très à l’aise, par exemple avec la langue. Et puis bien sûr, les Occidentaux font du vœu pieux. Ils pensent que tout le monde est d’accord, mais la personne qui n’a pas parlé est en fait totalement en désaccord. Personne ne le remarque, mais c’est une situation assez fréquente. Et euh et j’ai eu la chance d’aller régulièrement. Je vivais à Nagoya. Euh nous vivions à Nagoya et j’ai eu la chance d’aller très souvent à Tokyo euh pour rencontrer les gens de Tokyo à l’ouverture de la corona par Toyota. Ceux qui, d’une part, construisent la ville tissée euh sur le mont Fuji. Euh dont la première phase est maintenant terminée, donc il y a maintenant vraiment des gens qui y vivent. Donc cela vaut vraiment la peine d’aller voir ce que Toyota a fait là-bas. C’est une sorte de laboratoire pour la mobilité. Euh et aussi dans cette entreprise, il y avait la moitié des personnes embauchées de partout dans le monde. Donc c’était un laboratoire culturel très intéressant de voir l’interaction entre ces gars japonais et les gars du monde entier. Et ils ont également développé un système d’exploitation pour voitures qui s’appelle Arene. Que euh Toyota vendra aussi à d’autres constructeurs automobiles. Euh et puis j’ai eu des rôles pour Toyota Motor Corporation. En termes bien sûr, puisque j’étais le seul étranger là-bas, ils disaient, oh Willem, tu fais ça, tu ne ferais pas ça ? Donc j’ai eu euh de bonnes journées bien remplies, surtout avec les réunions vers 23h avec l’Australie vers l’Amérique du Nord. Euh et j’étais sponsor mondial pour le système de production Toyota et euh et pour les pratiques agiles. Et j’ai fait quelque chose que euh pratiquement, j’ai vu très peu de gens faire. J’ai donné une formation TPS à Toyota au Japon. Parce qu’ils n’avaient pas pratiqué euh le TPS partout dans l’entreprise et en particulier en IT, ils étaient très dépendants de fournisseurs externes qui ne faisaient pas d’agile ou de TPS. Et euh donc parce que j’avais pratiqué euh euh l’agile avec une saveur de TPS en Europe, je me suis retrouvé dans cette position pour les former, ce qui est très difficile. Ce n’est pas si facile pour une personne japonaise bien sûr d’accepter qu’un gars en Europe, un étranger, leur dise comment faire du TPS. Euh mais j’ai beaucoup appris en faisant cela. Euh et puis j’ai été sponsor pour d’autres choses. Donc l’incitation de ce que j’ai trouvé est euh quand j’ai commencé à faire de l’agile euh avec mon équipe en Belgique, l’équipe européenne, personne n’a remis en question pourquoi devrions-nous faire de l’agile ? Tout le monde a dit, oh, quelque chose de nouveau, faisons-le. Mais au Japon, ça ne marche pas comme ça. Ils ont demandé les fameux cinq pourquoi. Donc ils demanderont euh pourquoi pensez-vous que c’est mieux ? Et là, vous devez vraiment avoir une argumentation beaucoup plus forte pour leur dire pourquoi ce sera mieux. Et en faisant cela, à un moment donné, vous pouvez vous demander, est-ce vraiment mieux ? Donc il y a des questions comme oh, les exigences de mes utilisateurs ne changeront pas dans les cinq prochaines années. Pourquoi devrais-je faire de l’agile ? Alors bien sûr, je dis que c’est impossible. Je n’ai jamais vu d’utilisateurs qui ne changent pas d’exigences en cinq ans. Mais c’est bon, au Japon, vous voyez beaucoup de choses intéressantes. Il y a des choses qu’ils ont kaizen à mort pendant de nombreuses années et ils ont eu l’impression qu’ils étaient parfaits et qu’il n’y aurait aucune pause dans les cinq prochaines années pour changer quoi que ce soit. Donc Agile a laissé pour blanc dans ce cas. Ou euh d’accord, et si la migration n’est que technique ? Et j’ai dû dire, oui, mais la technologie aussi change. Donc si vous faites votre votre migration en cascade sur cinq ans, mais que la base de données que vous utilisez est DP2, et que lorsque vous avez fini, personne n’utilise DP2. Ce n’est pas mal d’être agile même pour la technologie. En tout cas, nous avons eu beaucoup de discussions intéressantes. La plus folle que je n’avais pas anticipée est euh il y a une agence au Japon appelée IPA. Ce n’est pas une bière. C’est l’agence IT quelque chose. Et euh ils disent en fait aux entreprises comment elles devraient travailler avec l’IT. Mais parce que c’est une organisation d’État, elles ne réagissent pas très rapidement aux nouvelles tendances. Donc elles n’avaient pas édicté euh de règles sur la façon de bien faire de l’agile. Et donc les gens reviennent me voir. Ils ont dit, désolé, nous ne pouvons pas faire d’agile parce que euh parce que l’IPA ne nous dit pas comment faire de l’agile. Euh je dis oui, mais nous sommes Toyota, la plus grande entreprise du Japon, tout le monde respecte Toyota, pourquoi ne commencerions-nous pas ? Ils disent, oui, mais c’est un problème informatique. Peut-être devrions-nous demander à NTT ou Fujitsu, une grande entreprise japonaise, de commencer par cela, et ensuite nous suivrons. Bien sûr, c’est un moyen très idéal de perdre quelques mois. Donc j’étais très en colère et nous nous sommes beaucoup battus à ce sujet. Mais finalement, l’IPA a fait quelque chose, nous les avons aussi mis un peu sous pression, et nous avons pu commencer. Et euh et aussi la question naturelle est, pourquoi ne pas simplement utiliser le système de production Toyota pour l’informatique ? Et c’est en fait plus ou moins ce que nous avons fait, mais nous pouvons utiliser le vocabulaire Agile euh et ou nous pouvons utiliser le vocabulaire TPS de Toyota. Donc au lieu de parler de la réunion debout du matin, nous pouvons l’appeler Akai, ce qui signifie réunion du matin et qui est utilisé tout le temps dans la production de Toyota. Donc vous devez un peu traduire le concept et ensuite vous réalisez que les gens de la fabrication sont en fait plutôt d’accord parce que c’est ce qu’ils voulaient faire depuis longtemps.

Euh d’accord. Donc à la fin, nous avions dans cette entreprise, cette entreprise informatique, environ 1 000 praticiens Agile. Euh je voulais atteindre 1 000, mais euh euh mais j’ai vu que, pour certaines raisons, ce n’était de toute façon pas du GPS. Donc je n’ai pas trop poussé pour que tout le monde soit à bord. Euh et je pense que ce n’est toujours pas le cas maintenant. pour parler de la réunion debout le matin, que j’appelle Asaichi, ce qui signifie réunion du matin et qui est utilisée tout le temps dans la production de Toyota. Donc il faut un peu traduire le concept et ensuite on se rend compte que les gens de la fabrication sont en fait pas mal d’accord car c’est ce qu’ils voulaient faire depuis longtemps.

Ok. Donc au final, dans cette entreprise, une entreprise informatique, nous avions environ 1000 praticiens agiles, trois ans. Et je voulais atteindre 1000, mais je me suis dit, oui, si pour une raison quelconque ce n’était pas le cas, la culture n’est pas le TPS, donc je n’ai pas trop poussé pour que tout le monde soit à bord. Et je pense que ce n’est toujours pas le cas maintenant.

Euh, donc, si nous regardons la maison traditionnelle du TPS, que je suppose la plupart d’entre vous ont vue. Mais alors je demanderai toujours pourquoi vous n’avez pas vu le pilier appelé Jidoka, car sans lui, le temple ne tient vraiment pas très bien. Euh, donc nous avons vraiment ceux-là. Pourquoi avons-nous ces deux colonnes ? Euh, historiquement d’abord, le Jidoka est une invention du premier travail de Toyota, qui était de fabriquer des métiers à tisser automatiques, le métier automatique. Euh, et là, l’idée de base pour la qualité est venue. Et puis le juste-à-temps est arrivé avec le fondateur, Saichi Toyota, et ensuite son fils, Kichiro, a fait du juste-à-temps parce qu’après la guerre, le Japon n’avait pas d’argent, n’avait pas d’espace de stockage. Ils ont donc dû trouver un autre moyen de fabriquer une voiture avec moins de stock et aussi un flux tiré, euh, ou essayer de satisfaire les clients un par un.

au lieu de produire beaucoup de choses à mettre sur un grand tas, comme c’était très facile à faire aux États-Unis. Euh, et donc je n’expliquerai pas tout, vous verrez pourquoi il y a des centaines de concepts dans le lean, mais je me concentrerai vraiment sur la partie Jidoka aujourd’hui. Euh, mais quand j’ai essayé, j’ai fait un doctorat à Strasbourg quand j’avais de 56 à 59 ans. Et euh, dans ce doctorat, j’ai essayé de cartographier euh, tous les concepts Lean et TPS que j’apprenais dans les usines aux temples, et c’est devenu très encombré parce que… Premièrement, chaque consultant a une autre version du temple, car bien sûr, ils doivent avoir leur propre version, euh, et euh, et l’endroit où ils mettent les choses est parfois à la base, parfois au milieu, parfois en haut et il n’y a pas de réelle cohérence. Alors ce que j’ai fait, c’est ceci, que bien sûr vous lirez tous en détail. Euh, alors j’ai pris tous les concepts que j’ai appris et je les ai regroupés avec des concepts principaux qui seront un peu plus lisibles, et pour donner suite à la conférence sur la philosophie que nous avons eue hier. Donc cela s’appelle une ontologie, euh, je l’appelle l’ontologie du Lean. Euh, et euh, euh, cela montre, certaines personnes peuvent l’appeler une carte mentale. Cela montre la relation entre les différents concepts. Soit dit en passant, c’est librement disponible car mon doctorat est.

peut être trouvé sur tesis.zh. Vous verrez le lien à la fin. Cela deviendra un livre qui sera un peu plus facile à lire. C’est mon objectif pour cette année. Donc le concept principal que j’ai trouvé est que, euh, vous voyez que le juste-à-temps et le Jidoka sont toujours des deux côtés pour rappeler aux gens qu’ils étaient les piliers.

Et puis en bas, vous avez les fondamentaux, la sécurité avant tout, l’amélioration continue, le Kaizen, qui est la visualisation et euh, le Monozukuri, qui signifie fabriquer des choses, donc l’art de bien fabriquer des choses. Mais pour bien fabriquer des choses, il faut d’abord fabriquer des personnes capables de bien fabriquer des choses. Donc et cela peut être des produits ou des services. Donc, sur la ligne du haut, vous avez les cases liées aux personnes. Vous avez le client en premier. Et à droite vous avez euh, Hitozukuri, donc toutes les techniques pour mettre les gens en premier et pour former pour laisser les gens grandir afin qu’ils puissent préparer les bons produits ou services. Et au centre en haut, vous avez la satisfaction des parties prenantes.

Euh, ce qui est très important car nous ne travaillons pas seulement pour faire un grand profit, mais nous voulons être durables sur une très longue période de temps, euh, disons comme 100 ans. Donc si je compare avec l’Agile, euh, il y a un certain nombre de choses que l’on retrouve dans l’Agile. Client…

Euh, le client d’abord, oui, si vous avez un bon product owner, quelqu’un qui connaît vraiment le travail du client et qui a une vision claire de ce que le produit devrait être, peut-être que vous pouvez mettre le client d’abord. Mais dans de nombreux cas, vous obtenez un product owner qui ne connaît pas très bien le travail, c’était peut-être la personne disponible dans l’entreprise pour vous soutenir, et pas nécessairement celle qui connaît le mieux le travail, et alors vous pouvez toujours en Agile livrer le mauvais produit, c’est ça. Euh, l’Agile est plus juste à temps.

Parce que vous livrez des morceaux plus petits de choses, euh, plus rapidement. Euh, et le Kaizen, oui, mais en Agile le Kaizen est par très petits incréments, mais il y a quelque chose de très important, c’est la direction, la boussole, qui s’appelle Hoshin Kanri. Euh, et si vous n’avez pas le Hoshin Kanri, vous pouvez avoir des équipes agiles qui vont vraiment dans toutes les directions. Et ne jamais rien accomplir parce qu’ils n’ont pas la vision à plus long terme, parce qu’ils pensaient que ce n’était plus nécessaire. Alors j’ai discuté avec Jeff Sutherland, qui a fondé Scrum, qui a fondé.

Il a dit, bien sûr, vous en avez besoin, mais comme il ne le dit pas dans son document, certaines personnes ont arrêté de le faire.

Euh, et puis, oui, la visualisation, bien sûr, vous avez des tableaux Kanban, vous avez Jira et ainsi de suite. Mais euh, parfois nous préférons toujours un bon vieux Obeya, qui est une pièce où d’un coup d’œil vous pouvez voir le statut de tout. Sur papier, bien sûr, le COVID a été terrible pour l’Obeya. Euh, les gens ne pouvaient plus se réunir. Donc beaucoup de choses ont été faites avec l’informatique, mais c’est peut-être un défi pour les informaticiens que personne n’ait été capable de faire quelque chose avec l’informatique qui soit à jour et qui ressemble à un Obeya papier. Donc il y a toujours une entreprise appelée IObeya, qui essaie de faire exactement ça. Mais pour moi, ce n’est pas encore tout à fait là. Euh,

Et puis je vais en venir aux choses plus positives. Donc, l’Agile ne satisfait pas toujours toutes les parties prenantes. Il n’y a pas grand-chose dans l’Agile sur le fait que vous devriez soutenir votre communauté ou des choses comme ça, ou votre pays ou le monde. Et euh, former les gens, oui, il y a un certain développement des personnes, peut-être que le scrum master euh, essaiera de développer les personnes, mais ce n’est pas aussi systématique que ce que vous trouvez chez Toyota. Euh, et puis finalement, il n’y a rien sur la sécurité d’abord.

Il n’y a rien sur la sécurité d’abord. Mais c’est sur l’environnement, la sécurité est vraiment primordiale et si vous ne le faites pas, c’est super dangereux.

Et à droite, euh, le Jidoka, que j’appelle parfois arrêter le temps. Mais vous verrez pourquoi. Euh, il y a très peu de choses sur cet aspect. Il y a une chose peut-être si vous faites un sprint et euh, vous avez une escalade d’obstacle.

Euh, cela peut être comparé à un Andon dans le Jidoka. Et donc l’objet aujourd’hui est euh, est le Jidoka. Euh, et bien sûr je peux parler pendant de bons jours de tous les autres. Donc, si je zoome sur l’ontologie, ce n’est probablement toujours pas lisible. Euh,

mais je vais, je vais expliquer essentiellement trois méthodes de Jidoka.

Euh, et euh, euh, tout d’abord, qu’est-ce que le Jidoka ? Qu’est-ce que cela signifie ? Les gens ont inventé des mots pour cela en anglais. Euh, certaines personnes l’appellent automation, mais comme le mot automation n’existe pas en anglais, ce n’est pas plus clair que de dire Jidoka.

Euh, tout ce qu’ils disent, c’est l’automatisation avec une touche humaine. Et euh, mais c’est trop long. C’est pourquoi la plupart des gens l’appellent Jidoka.

Et euh, pour ceux qui, euh, pour ceux qui lisent les caractères chinois, euh, Toyota a même modifié le caractère chinois pour avoir cela. Donc Jidoka normalement ne s’écrit pas avec le petit, c’est en fait une personne.

Caractère qui est dans l’élite rouge, normalement vous n’en avez pas besoin. Donc quand vous le tapez sur un clavier, vous n’obtiendrez pas cela. Toyota a ajouté cela, et c’est précisément la touche humaine. Donc ils ont mis un humain à gauche de ce caractère chinois. Euh, et euh, qu’est-ce que cela signifie ? C’est que, euh, vous voulez une machine qui fasse les choses aussi automatiquement que possible, mais vous voulez aussi que la machine se rende compte quand il y a un problème et qu’elle s’arrête d’elle-même. Et euh, l’origine de ceci.

Euh, cela pourrait être une décision.

Alors.

Donc ce que vous avez sur l’image, c’est le musée dans la maison du fondateur de la dynastie, euh, Saichi Toyota, et euh, sa mère travaillait là la nuit sur ce euh, métier à tisser. Et parfois le fil se cassait et donc elle devait arrêter son travail, réparer le fil et ensuite continuer son travail. Et son fils a vu que c’était vraiment un travail terrible et qu’il devait y avoir un moyen d’aider sa mère. Et euh, et ce qu’il a construit, cela lui a pris de nombreuses années car il a terminé seulement en 1924, c’est le métier à tisser de type G que l’on peut voir dans les musées de Nagoya, euh, qui s’arrête automatiquement lorsque le fil est cassé. Et c’est vraiment la clé pour deux choses. La première chose est une idée d’aider les gens et vous verrez que toute l’idée du Jidoka est d’aider les gens. C’est donc la signification profonde du Jidoka. Et puis aussi, cela lie l’homme et la machine.

Parce que si votre machine s’arrête quand il y a un problème, vous pouvez facilement avoir 30 machines et chaque machine dira, j’ai un problème, j’ai un problème, vous n’aurez pas vous n’aurez pas à regarder la machine tout le temps à une machine. Donc cela multiplie aussi la productivité par parce que vous avez cet appareil automatique. Je n’ai jamais su quand sa mère est morte, donc elle n’a jamais profité de cette invention, mais parce que c’est bien plus tard que le début de son activité, euh, mais euh, mais c’est l’intention, aider les gens. Et donc beaucoup de gens disent, Jidoka signifie arrêter la ligne, comme arrêter la ligne dans l’usine automobile. Oui, mais ce n’est qu’une chose visible. Pourquoi arrêtez-vous la ligne ? Vous arrêtez la ligne parce que l’ouvrier a un problème, il ne sait pas comment le résoudre et il demande de l’aide. Donc, c’est la chose clé. Et cette chose dans vos organisations, qui sont très diverses, qu’est-ce que cela signifierait pour vous de permettre à tout le monde d’arrêter la ligne et de demander de l’aide. Typiquement, vous avez de nouvelles personnes informatiques qui commencent dans l’entreprise, elles ne savent rien et elles ont du mal, et quand elles demandent à leurs collègues, leurs collègues sont tous très occupés à livrer quelque chose pour un client et personne n’est disponible pour les aider. Dans une usine Toyota, il doit y avoir quelqu’un de disponible parce qu’ils arrêtent l’usine et si personne ne vient, l’usine s’arrête, ce n’est pas très bon. C’est donc vraiment un moyen de forcer les gens à aider les gens. Et cela semble contre-intuitif car arrêter toute une usine représente un coût énorme, mais cela aide vraiment à concentrer les gens sur ce qui est vraiment important, et bien sûr, une fois le problème résolu, cela ne se produit plus.

Donc en informatique, en ingénierie informatique, car le Jidoka n’est pas seulement pour une usine, c’est aussi le titre de ma conférence aujourd’hui pour parler un peu aussi de l’ingénierie des produits. Euh, bien sûr, il y a quelques différences. Euh, en ingénierie et en production, essentiellement en production, vous répétez la même tâche plusieurs fois, parfois des milliers de fois par jour, euh, alors que si vous concevez une nouvelle voiture, vous avez peut-être une tâche que vous ne faites qu’une seule fois à chaque fois que vous concevez une nouvelle voiture, donc gagner une seconde n’est pas forcément très significatif. Mais au final, tous les principes du TPS s’appliquent.

Mais il faut que chacun connaisse son propre travail pour savoir comment les appliquer de manière intelligente. Et c’est ma passion maintenant d’appliquer le TPS à toutes les activités humaines, parfois très difficiles, nous pouvons très bien l’appliquer au gouvernement s’ils le veulent, nous pouvons l’appliquer à l’agriculture, nous pouvons vraiment l’appliquer à n’importe quoi.

Donc je veux parler maintenant des trois méthodes de Jidoka.

Vous connaissez l’Andon, si vous êtes français vous dites Andon. Non, pas tellement.

Ouais. D’accord, si j’attends assez longtemps, il y en aura plus. Ehm, vous connaissez le Poka-Yoke ? Ok, pas mal de mains.

Et peut-être que vous ne connaissez pas Jikotei Kanketsu ?

Euh, d’accord. Quelques-uns, quelques personnes. Peut-être la raison pour laquelle les gens ne connaissent pas Jikotei Kanketsu est qu’il est un peu plus difficile à prononcer.

Euh, mais c’est super important. Je n’hésiterais pas à dire que c’est vraiment l’un des secrets de Toyota. Parce qu’il y a quelque chose de difficile à faire, que les gens n’aiment pas faire, qui est ennuyeux à faire, donc aucun consultant ne passe de temps à l’expliquer aux gens. Alors s’il vous plaît, soyez patients avec moi et j’espère que vous comprendrez pourquoi je pense que c’est très important.

Et euh, aussi très contraire à ce que les êtres humains font naturellement. Donc, mais je vais rapidement passer à Andon et Poka-Yoke et me concentrer sur Jidoka. peu de gens. C’est peut-être une raison pour laquelle les gens ne connaissent pas le Jidoka et le Ketsu, c’est un peu plus difficile à prononcer.

Euh, mais c’est super important. Je n’hésiterais pas à dire que c’est vraiment l’un des secrets de Toyota. Parce qu’il y a quelque chose de difficile à faire, que les gens n’aiment pas faire, qui est ennuyeux à faire. Donc il n’y a pas de consultant qui passe du temps à l’expliquer aux gens. Alors, s’il vous plaît, soyez patients avec moi et j’espère que vous verrez pourquoi je pense que c’est très important.

Et euh c’est aussi très contraire à ce que les êtres humains font naturellement.

Nous allons donc toujours rapidement vers l’Andon et le Poka-Yoke et nous nous concentrons sur le Jidoka.

Andon. Andon est en fait une lanterne. An est aller et don est lanterne. C’est devenu une lanterne que vous avez dans la production. C’était une ancienne lanterne en papier. Euh, mais parfois les gens parlent des tableaux Andon qui peuvent montrer des couleurs comme le vert signifie que vous êtes sur la bonne voie pour votre production et le rouge signifie que vous êtes en retard.

Euh, et c’est aussi le cordon Andon. C’est donc le cordon que l’ouvrier tirera dans une usine pour arrêter la chaîne. Maintenant, les gens ont l’image que l’ouvrier a arrêté la chaîne et que des milliers de personnes ont arrêté de travailler, ce n’est pas comme ça. La chaîne est arrêtée et le superviseur vient et essaie de résoudre le problème dans le temps de cycle, ce qui signifie que le reste de la chaîne n’aura pas à s’arrêter. Mais si le problème n’est pas résolu dans le temps de cycle, alors le suivant s’arrête et progressivement tout le monde s’arrête. Donc ça se passe vraiment comme ça. Euh, il y a même aujourd’hui dans une usine Toyota, 2000 appels Andon par jour. Euh, parfois c’est une toute petite chose, mais vous avez de nouveaux travailleurs tout le temps qui ont besoin de soutien. Même si un travailleur veut aller aux toilettes, il tirera l’Andon, le superviseur viendra et fera le travail pendant les quelques minutes où il est aux toilettes. Donc, c’est aussi un Andon qui ne diminuera probablement jamais. L’objectif n’est donc pas d’atteindre zéro Andon.

Et il y a de toute façon toujours de nouveaux problèmes.

Euh, c’est très intéressant et j’ai passé beaucoup de temps à réfléchir à l’Andon en informatique. Parce que si vous êtes un jeune programmeur, c’est probablement un mauvais exemple, une jeune personne utilisant l’IA pour programmer quelque chose. Euh, vous avez un problème. Allez-vous arrêter les 8000 autres développeurs qui travaillent dans votre entreprise juste parce que vous avez un problème ? Donc ça semble un peu trop trop exagéré. Mais ce que Toyota a fait pour l’usine semblait aussi très exagéré.

Donc peut-être devrions-nous avoir quelqu’un d’assez audacieux pour l’appliquer plus que je ne l’ai fait moi-même dans mon service informatique. Euh, mais si vous êtes dans un sprint, euh et que vous avez peut-être six personnes dans l’équipe, euh alors ça a vraiment du sens de s’arrêter et de demander aux cinq autres personnes d’aider celle qui est bloquée. C’est donc ce qui pourrait se passer au cycle, au temps de cycle, euh n’aura pas d’impact sur l’autre équipe. Mais ensuite, si vous devez consolider ce que différentes équipes scrum ont fait, euh peut-être avez-vous aussi besoin de tirer l’Andon et de faire en sorte que les gens pensent que oh, ce module et ce module ne fonctionnent pas bien ensemble. Nous avons donc besoin d’un sprint supplémentaire pour les faire fonctionner ensemble. Donc cela pourrait aussi être une bonne décision.

Euh, et euh pour oui, l’escalade des obstacles à la direction générale. Quand les gens ont commencé à faire de l’Agile dans mes équipes, j’ai dit, euh, pourquoi je pensais que vous viendriez me voir tous les jours avec des obstacles parce qu’il y a des choses qui ne fonctionnent pas et que vous ne pouvez pas résoudre.

Pourquoi tu ne viens jamais me voir ? Donc quelque chose ne fonctionne pas si les gens euh baissent les bras et disent, oh oui, c’est de toute façon ce qu’ils ne m’ont jamais dit auparavant. Donc on n’essaiera même pas de le résoudre maintenant. Donc vous devez vraiment encourager les gens à faire remonter les obstacles à la direction générale. La bonne chose pour cela est l’Obeya, ce qui signifie la grande salle où vous mettez l’état de tous les projets et où le patron vient non pas pour dire, hé, vous avez une situation problématique mais projet, qu’avez-vous fait ? Mais vous dites, oh, là je vois que vous avez un problème, comment puis-je aider ?

Alors oui, c’est ce que je viens de dire.

Euh, donc le Poka-Yoke. Le Poka-Yoke est en fait meilleur que l’Andon parce que l’Andon, c’est vous avez un problème et vous dites que vous avez un problème. Mais le Poka-Yoke, c’est vous assurez que vous n’avez pas de problème. Normalement, je devrais donc commencer par le Poka-Yoke. Si vous avez de nombreux bons Poka-Yokes, vous devriez avoir moins d’Andon. Euh, Poka-Yoke signifie protection contre les erreurs. Dans le passé, ils disaient Bakayoke, Baka signifie fou. Euh, mais pour différentes raisons politiques, ce mot a changé et nous disons toujours « foolproof » en anglais. Euh, c’est donc un dispositif anti-erreur pour empêcher, par exemple, si l’ouvrier prend la mauvaise pièce pour la voiture qui arrive, euh, vous entendez un bip bip et il sait, oh, il a pris la mauvaise. Je dois prendre ici. Il peut donc y avoir 1000 Poka-Yokes dans une usine.

Euh, nous travaillons aussi dans le domaine de la santé et j’ai toujours peur que si vous allez à l’hôpital, il y ait peut-être deux ou trois Poka-Yokes pour éviter les erreurs. Mais dans une usine Toyota, vous avez des milliers de Poka-Yokes. Mais dans un hôpital, je peux perdre la vie. Alors je les encourage vraiment à avoir plus de Poka-Yokes pour éviter cela.

Euh, et oui, je pense que oui, pour l’informatique, vous avez une vérification pour les comptes bancaires. Donc, si vous tapez le mauvais, il vous le dira.

Euh, au moins toutes les 97 erreurs, c’est peut-être toujours la mauvaise, mais dans la plupart des cas, il la détectera. Ou affichez votre adresse sur la carte et ensuite vous pensez que vous êtes dans une ville mais vous êtes au milieu de nulle part. Vous pouvez immédiatement voir que l’adresse est incorrecte. Il existe de nombreux exemples de ce genre.

Dans la vie quotidienne, euh, normalement je le fais de manière interactive, mais ce serait difficile dans cette pièce. Euh, avec une station-service, qu’est-ce que c’est ?

Alors oui, je pense que vous avez dit la bonne chose, mais je ne suis pas sûr d’avoir entendu. Mais euh, vous ne pouvez peut-être pas mettre euh du diesel dans votre voiture à essence. Mais malheureusement, vous pouvez mettre votre essence dans une voiture diesel, ce qui signifie que ce n’est qu’un demi Poka-Yoke. Cela vous aidera un millième de deux. Donc faites attention si vous avez une voiture diesel, ça ne marche pas.

Euh, ou des choses comme euh oui, la ceinture de sécurité. Euh d’accord, si vous démarrez sans votre ceinture de sécurité, la voiture fera bip bip, ce n’est pas un vrai Poka-Yoke si votre voiture démarre. Votre voiture ne démarre pas, c’est plutôt un Poka-Yoke. Ensuite bien sûr, en France, les gens me disent, oh, c’est facile, tu le mets et tu t’assois dessus. Oui, donc il y a toujours, il y a toujours un dicton que je connais.

Euh, ou le distributeur automatique, maintenant ils ont remarqué que s’ils vous rendent votre carte avant de vous donner l’argent, il est plus probable que vous n’oublierez pas votre carte. S’ils vous donnent l’argent, vous partirez avec l’argent et oublierez votre carte, qui sera avalée par la machine. Vous avez aussi le Poka-Yoke. Et euh, ou dans le métro, il y en a quelques-uns, je ne suis pas sûr pour Paris, mais certains métros où vous mettez votre carte, vous pouvez oublier votre carte dans la machine et ensuite vous passez de l’autre côté. Ce n’est pas votre votre ticket. Certains métros vous forcent à prendre votre ticket pour le récupérer, sinon la porte ne s’ouvre pas. Mais si vous y pensez, vous pouvez avoir des Poka-Yoke partout dans votre vie. Et c’est ce que j’ai montré avec un coussin à droite, vous vous demandez peut-être ce que c’est. Euh, c’est juste que euh, nous avons un système d’alarme chez nous. Si le soir, nous mettons le système d’alarme en bas mais pas en haut. Donc, si nous sommes un peu fatigués le matin, nous descendons les escaliers et l’alarme se déclenche. Donc, nous avons juste mis un coussin en haut des escaliers et euh, quand nous voyons le coussin, nous savons que nous devons désactiver l’alarme. Juste pour dire que vous pouvez vraiment l’appliquer dans votre vie quotidienne.

Et certains Poka-Yokes sont bons, d’autres ne sont pas si bons. Euh, donc on va un peu vite là-dessus, mais ce sont des exercices que je fais. Donc, une chose typique avec une machine à café qui a des tasses. Si vous n’avez pas de chance, vous allez et le précédent a pris la dernière tasse et vous n’avez pas de tasse. Il vous faudra un certain temps pour prendre votre tasse. Alors, je demande aux gens ce que vous feriez pour éviter cette situation ? Il est intéressant d’apprendre la conception du Poka-Yoke parce qu’il y a des gens qui disent, oh, il suffit de mettre quelqu’un à côté de la machine qui la remplira toujours. Oui, mais c’est un Poka-Yoke très coûteux.

Euh, et nous nous avons eu d’autres, je n’ai pas encore la solution parfaite parmi toutes les réponses que j’ai eues dans de nombreux endroits du monde. Mais euh une idée était d’avoir une tasse rouge un peu avant la fin et la personne qui prend la tasse rouge est celle qui est obligée de recharger. Et sinon, tout le monde verra qui a la tasse rouge. C’est peut-être un peu trop de désignation du doigt, a dit un détail. Quoi qu’il en soit, réfléchissez bien à votre conception et n’hésitez pas à itérer et à trouver de meilleurs Poka-Yokes, cela vous aidera beaucoup. Euh, et puis une chose typique en informatique est que vous savez, vous avez toujours le disque qui est rempli à 80% et ensuite il vous le dit. Et puis personne ne s’en soucie parce qu’il y a des milliers d’autres messages pour les opérateurs et puis quelques jours plus tard, il est rempli à 100% et le système s’arrête. Je suis sûr que personne n’a eu ça dans sa carrière. Et bien sûr, si vous voulez un vrai Poka-Yoke, vous avez parfois besoin de donner euh plus de droits aux, par exemple, aux opérateurs qui sont là la nuit. Ils peuvent le voir, mais ils n’ont pas l’autorité d’augmenter la taille du disque ou de forcer d’autres personnes à faire quelque chose à ce sujet. Donc, vous devez vraiment concevoir des moyens pour le faire, pour vraiment forcer les gens à faire quelque chose parce que c’est un problème sérieux.

Ceci est euh un peu des exemples pour l’informatique.

Donc on ne pense pas toujours que c’est un Poka-Yoke, mais juste l’itération obligatoire euh l’indentation, pardon, dans la programmation Python ou dans euh vous il y avait une liste avec toutes sortes de parenthèses. Si votre éditeur de programme vous force à indenter, alors vous verrez que vous avez oublié des choses visuellement. Euh, maintenant bien sûr, il y a des choses comme le linting, euh, qui euh empêchent les erreurs directement au moment du codage. Donc, ils vous diront, pas bien, pas bien au moment où vous écrivez le code. Donc, bien sûr, c’est moins cher de résoudre le problème à ce moment-là.

Euh, et pour les risques de cybersécurité, il y a une notification immédiate des injections SQL, ce qui peut être très dangereux plus tard. Au lieu d’avoir des gens qui vérifient plus tard ce que euh euh et d’être en colère contre les gens parce qu’ils n’ont pas regardé cette injection SQL et maintenant nous avons eu une fuite de données en production. Euh, donc le suivant, je l’ai déjà dit. Euh, les utilisateurs de systèmes informatiques. Euh, j’ai déjà donné quelques exemples. Oui.

D’accord. Maintenant, c’est la diapositive la plus technique que j’ai et je parle de choses que je n’ai jamais faites moi-même partiellement. Euh, mais vraiment le langage que vous choisissez pour programmer peut être meilleur ou pire, peut être peut avoir plus de Poka-Yoke intégrés. Une chose très célèbre est les nouveaux langages sûrs parce que les pointeurs nuls créent beaucoup de problèmes. Il existe donc des langages qui ne vous permettent pas d’avoir des pointeurs nuls, ce qui semble être le cas de Kotlin, Rust et Swift. Euh, et euh certains langages l’ont implémenté en option, ce qui n’est pas idéal, ils doivent le faire pour des problèmes de compatibilité, mais euh cela signifie qu’ils ne vous forcent pas. Ce n’est donc pas un Poka-Yoke complet.

Ensuite les langages fonctionnels, vous pouvez en déduire ce que c’est. Cela existe, il y a un langage appelé Lean. Est-ce que quelqu’un a programmé en Lean dans la salle ? D’accord, je dois vous parler parce que euh, c’est drôle que le langage s’appelle Lean et je ne pense pas que ce soit un lien avec lui, je ne sais pas. Alors vous me direz. Euh, intérêt et programmation axée sur les tests. Donc encore une fois, si vous connaissez le concept du Poka-Yoke, il est plus facile de reconnaître un Poka-Yoke ou de reconnaître l’absence d’un Poka-Yoke et de faire le bon choix d’outils.

Ensuite Jidoka, Jidoka et Ketsu. Bien, je suis là avant la fin de l’heure parce que c’est mon social.

Euh, donc ça signifie Ji si votre tarif, c’est le premier caractère. Kote signifie processus et Ketsu signifie complet. Donc ça dit ce que ça dit. Cela signifie que vous êtes capable de compléter le processus par vous-même.

Alors euh, en anglais, ils ont trouvé le nom de qualité intégrée avec appropriation. Bien sûr, si les gens ne se soucient pas de la qualité de leur travail, il est peu probable qu’ils fassent du bon travail par eux-mêmes, mais ce n’est pas le cas le plus fréquent. Le cas le plus fréquent est que les gens ne savent pas ce qu’est un bon travail.

Alors, quand le responsable qualité de Toyota a réfléchi profondément aux raisons de tant d’erreurs de qualité. Il a pensé à l’épicier du coin de la rue. Il a dit, pourquoi, pourquoi l’épicier souriait-il habituellement ? Il sourit parce qu’il a un contact, un contact direct avec ses clients, et quand les clients trouvent les produits bons, ils le lui disent. Donc il reçoit de bons retours qui le motivent. Ainsi, lorsqu’il y a un problème, le client le lui dira aussi et il aura l’occasion de résoudre le problème plus rapidement parce qu’il reçoit le feedback non pas indirectement par l’intermédiaire de nombreuses autres personnes. Et c’est vraiment la philosophie de base derrière le Jidoka et le Ketsu.

Ainsi, les employés, et sûrement dans les grandes entreprises ce n’est très souvent pas le cas, les employés doivent comprendre la valeur de leur travail. Euh, ils doivent avoir un sens des responsabilités et de la fierté pour leur travail. Comment pouvez-vous, si vous faites quelque chose sans savoir qui en fera quelque chose ou non, il est difficile de ressentir la fierté et la contribution à l’entreprise. Un retour immédiat favorise une amélioration plus rapide, un retour positif augmente la confiance en soi et le travail devient plus intéressant grâce à cela.

Donc la manière typique de faire de l’assurance qualité dans le passé était : vous faites le travail, vous livrez la voiture et à la fin le département qualité arrive et dit : c’est très mauvais. Ce n’est pas d’abord, vous avez beaucoup de monde dans le service qualité et leur travail est de dire aux autres que leur travail est mauvais. Donc leur travail est nul et celui des autres aussi. Donc, la logique du Jidoka ici est d’intégrer réellement la qualité dans chaque processus et de pouvoir juger de la qualité de chaque processus.

Donc, c’est pourquoi je dis que cela semble facile en théorie, mais c’est très difficile à mettre en pratique. les retours augmentent, leur confiance, et le travail devient plus intéressant grâce à cela. Alors, la façon typique de faire de l’assurance qualité par le passé était que vous faites le travail, vous livrez la voiture, et à la fin le département qualité arrive et dit, c’est très mauvais. Ce n’est pas, d’abord, vous avez beaucoup de personnes dans le département qualité et leur travail est de dire aux autres que leur travail est mauvais. Donc leur travail est, euh, de la merde, et le travail des autres est, euh, Donc, la logique du JKK ici est vraiment d’intégrer la qualité dans chaque processus et de pouvoir juger la qualité de chaque processus. Ceci et c’est pourquoi je dis que cela semble facile en théorie, mais c’est très difficile à mettre en pratique. Nous ne sommes que deux dans mon entreprise et nous essayons de le faire ensemble et bien sûr, souvent je demande à ma femme de faire quelque chose et elle a compris quelque chose de différent et puis nous nous disputons. Et si vous voulez le faire très bien, cela prend du temps. On ne veut pas toujours prendre ce temps et ainsi de suite. Donc, en gros, vous avez des conditions nécessaires et des critères de jugement. La condition nécessaire est d’avoir une bonne conception de votre produit de processus, d’avoir un bon processus et d’avoir un opérateur compétent. Si vous demandez à quelqu’un de faire quelque chose pour lequel il n’est pas formé, il est très probable que le résultat soit mauvais. Euh, le critère de jugement est aussi très intéressant car la personne est-elle vraiment capable de vérifier par elle-même que la qualité est bonne ? Si ce n’est pas possible, euh, ça ne marchera pas. Ce ne sera pas de bonne qualité. Et plus important encore, l’autorité d’arrêter. C’est pourquoi j’ai Andon deux fois ici si l’opérateur n’est pas autorisé à arrêter lorsqu’il y a un problème, euh, bien sûr, il y aura des problèmes parce qu’ils sauront que leur qualité est mauvaise mais ils ne sont pas autorisés à arrêter, donc ils donneront la mauvaise qualité au suivant, par exemple, parce qu’il y a une échéance. Euh, donc, donc l’autorité d’arrêter et la compétence de juger. S’ils n’ont pas la compétence de juger la qualité, ils ne savent pas à quoi ressemble le bien, donc ils le donneront simplement au suivant et le suivant ne sera pas satisfait. Si vous avez établi tout cela, votre client interne ou externe sera satisfait. Et vous aurez toujours une boucle de rétroaction avec la prochaine fois. Euh, encore une fois, ce n’est pas facile à faire. Si certains d’entre vous commencent à le faire dès demain, et que cela fonctionne, s’il vous plaît dites-le moi parce que je n’ai pas tant d’entreprises qui le font bien. J’espère que ce tutoriel aussi, mais Donc, il y a, euh, des étapes pour établir les processus de travail JKK et si vous connaissez la méthode de résolution de problèmes de Toyota, elle a aussi huit étapes et ici c’est la même chose, les étapes un à trois, quatre, cinq, c’est en fait juste de la planification. Six est l’exécution réelle, sept est la vérification et huit est l’action. C’est donc un cycle PDCA où le P de planification est la première question. Donc, vous clarifiez d’abord l’objectif et la cible. Si les gens ne connaissent pas le but de leur travail, ils ne sont pas motivés à faire leur travail. Euh, vous visualisez clairement le résultat final. À quoi cela ressemble-t-il pour vous ? Et ensuite, c’est ce que vous devez vous efforcer d’obtenir avec qualité. Ensuite, vous détaillez le processus et la procédure, puis vous définissez ces critères de jugement et ces conditions nécessaires que j’ai montrées. Euh, et ensuite vous accomplissez le travail et bien sûr vous trouverez des choses que vous pouvez améliorer et c’est l’étape sept, vous réfléchissez au travail et vous transmettez les connaissances acquises à d’autres personnes qui peuvent également améliorer leur travail.

Beaucoup de gens, surtout en Occident, trouvent cela ennuyeux à faire, alors ils ne le font pas et ils n’ont pas de qualité. Donc, je pense que nous devons nous discipliner pour le faire. Et il y a cinq niveaux de maturité dans le JKK. Vous commencez toujours par avoir des portes de qualité parce que la qualité n’est pas encore bonne. Vous essayez de voir quel type de problèmes vous avez. La porte de qualité s’arrête et vérifie, donc là vous êtes toujours dans une phase de qualité externe. Ensuite, chaque problème de qualité que vous trouvez, vous le signalez à l’endroit où le problème est survenu et vous faites essentiellement une résolution de problèmes à la manière de Toyota. Donc vous résolvez ces problèmes un par un. C’est le numéro trois, et seulement alors vous établissez les conditions nécessaires et les critères de jugement. N’essayez pas de tout faire en même temps car nous avons essayé de nombreuses fois, cela ne fonctionne pas. Il faut vraiment le faire étape par étape. Donc, et je n’aime pas entendre que seuls les Japonais peuvent faire ça parce que ce n’est jamais vrai. J’ai vu des gens dans les usines le faire de n’importe quelle nationalité. Mais oui, c’est un travail difficile, mais une fois que vous l’avez fait, alors nous revenons à ce que nous avons dit hier. Vous êtes content parce que le travail coule, n’est-ce pas ? Et votre collègue ne vous donne pas de la merde parce qu’ils ont aussi fait ça et vous ne donnez pas en retour au suivant parce que vous l’avez fait. Donc c’est vraiment ce que nous devrions tous essayer de euh, euh, essayer d’avoir. Euh, je je vais sauter un peu mais ce n’est qu’un exemple, un exemple informatique simplifié, euh, où une personne développe un programme et le donne à un opérateur, euh, et, euh, euh, vous regardez les étapes. Ainsi, la personne qui écrit le programme observe le travail du client, prépare les exigences, développe le programme, teste le programme, présente le programme. Je sais que maintenant nous faisons beaucoup de choses DevOps et ainsi de suite. Mais ce que j’ai vu de nombreuses fois dans ma carrière, c’est que l’opérateur devait exécuter des programmes et ils se plaignaient parce que, euh, parce que les développeurs ne savaient pas quel était le travail d’un opérateur et donc ils ne concevaient pas de programmes pour être exécutés en douceur. Et quand il y avait un problème à 2h du matin, personne ne pouvait aider. La documentation n’était pas bonne. Encore une fois, vous devez vérifier qu’il y a une bonne conception, mais dans la conception pour de bonnes opérations. La meilleure façon est d’envoyer les développeurs faire des opérations et de les renvoyer aux développeurs. Ceux qui ont fait cela ont beaucoup mieux compris. Euh, il doit y avoir des critères d’aller-retour, comme nous l’appelons, euh, en japonais, euh, basés sur des problèmes réels qui se sont produits par le passé, ce qu’il faut faire à leur sujet. Euh, et bien sûr, l’opérateur doit être capable, doit comprendre ce qu’il fait, ce qu’il met en confiance et éliminer le défaut de beauté, ce qui, euh, est appelé Poka Yoke pour ceux qui ont appris le manifeste lean.

Euh, et puis, oui, vous avez des critères de jugement. Donc, un bon opérateur aime recevoir ce programme en raison de sa convivialité, bien sûr, le développeur conçoit-il, je ne le mets pas en production, par lui-même, peut-être pas parce que la date limite est aujourd’hui, l’utilisateur le veut aujourd’hui, donc il sait qu’il n’a pas la documentation mais mettons-le en production.

Euh, et la capacité de juger. Un développeur peut-il juger ce qu’est un bon programme pour l’opération ? Le programmeur le sait-il même ?

Et puis vous faites du PDCA, vous obtenez, très souvent quand un programme est en production,

le développeur fait autre chose, n’obtient pas tant de choses du programme en production. Comment organiser la boucle de rétroaction.

Euh, d’accord, je sais que ce n’est pas un sujet sur lequel vous faites des ateliers. Il y a ces petites choses. Donc, en général, et c’est énorme, mais il y a de très grands avantages à faire du JKK. C’est un investissement initial, c’est toujours une partie difficile. Mais cela vous aide à éliminer l’optimisation locale, à créer des opportunités pour les managers de vérifier les progrès, à approfondir les communications entre les divisions, à maximiser la force unique de chaque partenaire, en augmentant le partage d’informations, à être appliqué pour obtenir le feedback à discuter, réduire les réunions, révéler l’irraisonnable pour améliorer, améliorer, améliorer cela. Réduire les échecs et les non-conformités, augmenter la productivité et augmenter la motivation. Alors bien sûr, tout le monde dit, pourquoi ne le faisons-nous pas, oui ? Parce que c’est difficile, c’est difficile et il faut y mettre du travail et il est toujours plus facile de trouver un raccourci, ce qui semble bien pour aujourd’hui, mais sera un problème demain. Bien sûr, votre propre DevOps est, euh, un exemple de tension entre le juste-à-temps et le Jidoka. Euh, parce que vous, le développement essaie d’être juste à temps, mais lorsque vous mettez en œuvre, euh, parfois vous avez un rejet parce que, euh, ce n’est pas sûr ou cela ne respecte pas certaines normes et ainsi de suite. Euh, et donc vous devez vérifier que chaque changement est un bon changement. Kaizen signifie changer en bien, n’est-ce pas ? Donc, Kaizen n’est pas juste un changement, c’est un changement pour quelque chose de mieux. Donc, vous devez tout vérifier.

Maintenant, j’ai juste deux diapositives sur l’ingénierie informatique spécifiquement.

Euh, donc j’ai déjà dit, euh, de réduire cinq secondes d’opération à quatre. Quand vous l’avez mille fois par jour, cela a du sens en production. En ingénierie, d’accord, si vous avez un nouveau concept de voiture tous les trois ans, euh, réduire cinq secondes pour une opération n’a pas de sens. Cela ne signifie pas que les principes du Lean ne s’appliquent pas, cela signifie simplement que vous devez les appliquer de manière intelligente. Et puis pour une autre discussion, il y a beaucoup de choses que je peux dire sur l’ingénierie concourante basée sur les ensembles. euh, la base de données de connaissances que Toyota conserve depuis 50 ans, même si c’est juste sur papier, au moins vous n’avez pas eu 20 générations de systèmes qui étaient les données entre-temps. And je vais dire en français, vous, pour ceux qui parlent français, vous connaissez peut-être le livre qui s’appelle au cœur de l’ingénierie Toyota qui a été écrit par le chief ingénieur français de la voiture qui a été faite entre Peugeot, maintenant Stellantis et Toyota. Donc les la 108 de Peugeot euh et la Citroën C1 et chez Toyota c’était l’Aigo. C’est trois voitures étaient faites dans dans la même usine. Et donc un chief ingénieur français qui a travaillé avec les japonais.

Et je trouve vraiment intéressant que ce gars, Olivier Stolier, il est employé par Stellantis, mais quand vous lisez le livre, vous voulez travailler pour Toyota parce qu’il est totalement épris de Toyota dans le livre. Et c’est plein d’anecdotes et c’est vraiment facile à lire donc je recommande si vous êtes intéressé par l’ingénierie d’acheter ce livre. Vous pouvez l’acheter pour moi mais plus logiquement ici vous pouvez l’acheter chez SDC, vous pouvez aussi. Et puis il y a des livres sur, euh, le système de développement de projets de Toyota, euh, Morgan et Laker est une partie très célèbre. Mais écrit par des gens qui n’ont jamais fait d’ingénierie chez Toyota, ils ont beaucoup étudié mais ils n’étaient pas chez Toyota. Donc, ils sont toujours plus que ce qu’il y a. Donc un processus produit allégé et ainsi de suite.

Et puis je dois dire un dernier mot sur l’ingénieur en chef.

Euh, parce que la notion d’ingénieur en chef chez Toyota, euh, est un mystère pour beaucoup de gens. Parce que, euh, quand Toyota concevra une nouvelle voiture, euh, ils nommeront toujours un ingénieur en chef. L’ingénieur en chef a la responsabilité complète de la voiture, c’est une responsabilité de profit et perte. Mais l’ingénieur en chef n’a pas toutes les personnes qui travaillent sur la voiture sous ses ordres, car il y a des femmes ingénieures en chef chez Toyota. Et, euh, euh, devenir ingénieur en chef, c’est vraiment comme si vous étiez un demi-dieu, oui ? Euh, vous devez être entièrement respecté au sein de l’organisation pour que l’organisation vous confie ce rôle d’ingénieur en chef. Donc cela signifie que les gens qui font ça, ils ont vraiment une autorité, euh, une autorité naturelle. Mais ils l’utilisent avec beaucoup de précaution. Donc, ils dépassent très rarement les décisions que prennent les grands phylos, comme l’atelier de carrosserie, l’atelier de peinture, l’assemblage, etc. Euh, mais cela arrive très rarement qu’ils le fassent. Quand ils le font, les gens respectent leur décision. Donc j’imagine que dans certaines cultures, c’est très difficile à mettre en œuvre.

Euh, mais ça marche, oui ? Euh, et c’est aussi pourquoi toutes les voitures Toyota ne sont pas les mêmes. Euh, par exemple, Shiko Kaku, qui est la femme ingénieur en chef qui a conçu la Toyota Yaris, elle a été la première femme ingénieur en chef.

Euh, elle a conçu un peu plus d’espace à l’arrière pour une femme et des choses comme ça, donc cela en fait une voiture plus adaptée aux femmes. C’est donc vraiment la touche personnelle de l’ingénieur en chef. Euh, et certains préfèrent euh, euh, préfèrent avoir un système audio parfait, alors ils diront un peu plus d’argent sur autre chose, mais le résultat de la voiture et les ventes, tout le cycle de vie de la voiture sera attaché à cet ingénieur en chef. Ils viennent au salon de l’auto pour présenter, faire le marketing et les ventes de la voiture, mais ils ont aussi fait toute l’ingénierie auparavant. C’est donc vraiment un travail incroyable. L’un des plus célèbres est celui qui a fait le précédent. Euh, quand il a appris qu’il serait ingénieur en chef, il a dit à sa femme, elle a dit, d’accord, je vais apporter un lit au travail et je resterai ici pour les trois prochaines années, au moins, mais il est devenu président de Toyota après. Euh, et si vous pensez à l’informatique, ce que j’ai vu très souvent, c’est que lorsque vous avez besoin d’un Product Owner, tout d’abord, le Product Owner n’est pas toujours considéré comme un demi-dieu.

Euh, et vous pouvez vraiment obtenir la personne qui a du temps, qui n’est normalement pas la personne qui connaît le mieux le processus et qui peut concevoir le meilleur projet. Alors, s’il vous plaît, commencez dès maintenant à recruter le personnel ici et n’hésitez pas à les rendre permanents. Mais du personnel avec humilité, c’est-à-dire que l’ingénieur en chef de Toyota ne montre pas trop d’arrogance. C’est donc aussi un travail très difficile qu’ils font.

Et donc, en résumé, nous voulons créer un flux tiré à partir du besoin du client. Donc c’est le pilier très connu, euh, du juste-à-temps, le flux tiré du TPS. Et le Jidoka fait le contraire, le Jidoka arrête le flux. Et c’est vraiment cette contradiction apparente qui vous rendra de plus en plus performant, car chaque fois que vous arrêtez le flux, c’est pour améliorer quelque chose. Donc, en arrêtant le flux, vous vous assurez que vous arrêterez le flux de moins en moins à l’avenir. Et bien sûr, je dois dire quelque chose sur l’IA, c’est un appareil. S’il vous plaît, réfléchissez profondément à ces concepts et utilisez l’IA lorsque cela a du sens. Vous pouvez utiliser l’IA pour vous aider à concevoir un bon Poka Yoke, pourquoi pas ? Mais n’oubliez pas d’avoir le Poka Yoke, d’avoir l’Andon, d’avoir.

C’est tout. Euh, merci, pour ça je peux dire ça. Euh, ce rapport est pour mon doctorat, il fait 250 pages en anglais et un résumé en français à la fin. Euh, mais oui, j’essaie de le mettre sous une forme plus facilement consommable, mais vous avez là aussi l’ontologie complète. Euh, et et vous pouvez nous joindre à l’Institut quand vous voulez. Merci.