Utiliser la technologie pour améliorer la société pour tous.

[00:00:00] Alistair Croll : [00:00:00] Bonjour et bienvenue à un autre épisode de FWDThinking. Je suis le président de la conférence FWD50, Alistair Croll. FWDThinking est une production de la conférence FWD50 sur le gouvernement numérique et cet épisode est rendu possible en partenariat avec IBM. Aujourd’hui, je vais m’entretenir avec Marianne, auteur et experte en modernisation des TI. Elle a travaillé sur la modernisation de l’héritage, en faisant en sorte que certains des systèmes monolithiques massifs sur lesquels la société fonctionne fonctionnent sans problème et entrent dans l’ère moderne. Et ce que j’ai trouvé le plus intéressant dans son nouveau livre, Kill It with Fire, c’est la faible part qu’il consacre à la technologie et la part qu’il consacre aux facteurs humains, au calcul des risques, à la permission donnée aux gens d’entrer dans le contexte des systèmes, à la gestion des équipes, à la manière d’utiliser les crises comme un avantage. C’est une discussion fascinante qui a duré un peu plus longtemps que prévu, et nous sommes incroyablement chanceux d’avoir eu la possibilité de parler franchement avec Marianne.

[00:01:04] Je vous invite donc à me rejoindre dans ce voyage vers la modernisation de l’informatique avec Marianne Bellotti, auteur de Kill It with Fire. Et je dois être franche, Marianne, en lisant ce livre, j’ai eu une sorte de syndrome de stress post-traumatique parce que tous mes souvenirs de l’intégration de grands systèmes et de l’innovation dans les grandes entreprises, de la connectivité des mainframes aux clients PC et de la migration vers le cloud, toutes ces choses sont revenues à la surface. Et c’est un livre fantastique. Merci beaucoup de vous être joint à nous. 

[00:01:29] Marianne Bellotti : [00:01:29] Eh bien, merci de m’avoir invitée. Je suis ravie d’être ici. 

[00:01:32] Alistair Croll : [00:01:32] Alors, tout d’abord, pourquoi ne pas parler un peu de vous, et ensuite j’aborderai les nombreuses, nombreuses questions que j’ai posées dans mon livre très griffonné. Et si vous n’avez pas encore acheté le livre, vous devriez probablement aller le chercher parce qu’il est plein de flashbacks et j’ai passé les derniers jours à le consommer. Alors, qui es-tu ? Et de quoi parle le livre ? 

Marianne Bellotti : [00:01:49] Oui, j’ai une sorte de carrière indirecte intéressante dans le domaine de la technologie et de la modernisation de l’informatique en particulier. J’aime parfois me qualifier d’ anthropologue récalcitrante, car j’ai fait toutes mes études en anthropologie et en sciences de l’organisation. J’ai commencé à m’intéresser à la programmation parce que mon père est un programmeur informatique ou il est maintenant à la retraite. Il était programmeur informatique et travaillait sur de vieux systèmes mainframe COBOL, un peu de Java vers la fin de sa carrière dans de grandes banques. Et donc, depuis un très jeune âge, comme la fin des années 90, même comme mes, mes plus jeunes souvenirs sont d’interagir avec de très, très vieux ordinateurs et les ordinateurs étaient toujours dans ma maison, comme empilés 3 profondeurs dans mon sous-sol. Et donc à partir de l’âge de 14 ans, j’ai commencé à construire des ordinateurs à partir de pièces détachées, à surfer sur Internet, à écrire du code et ce genre de choses. Donc, au moment où je suis entré dans une sorte d’environnement universitaire où l’on devrait normalement décider officiellement de devenir un informaticien et

[00:03:00] passer par tout cela, ce travail de développement hautement discipliné, j’en avais un peu marre. Je l’avais fait pendant un certain temps et je voulais faire d’autres choses. Je voulais voir le monde, je voulais, sont très classique comme, je veux aller là-bas et sauver le monde attitude de type. J’ai donc passé une grande partie de ma vingtaine à fuir la technologie, en essayant de 

établir ma carrière dans un autre domaine. Mais j’en suis venu à réaliser que les compétences de base que j’avais en interagissant avec les ordinateurs et en ayant des connaissances techniques étaient souvent la chose la plus précieuse que j’apportais à beaucoup de ces organisations.

[00:03:35] Et donc j’ai progressivement commencé à faire de plus en plus de travail de type technique pour beaucoup d’organisations à but non lucratif pour lesquelles je travaillais, des groupes de développement international, et cela m’a finalement conduit à m’engager à devenir ingénieur logiciel professionnel à plein temps et à prendre un emploi avec l’ONU en travaillant sur leur projet d’échange de données humanitaires depuis le tout début.

[00:04:00] C’est une histoire d’origine en gros. J’ai vraiment apprécié mon travail à l’ONU et j’ai travaillé sur la modernisation de l’héritage pour la ville de New York et pour d’autres grandes organisations. Et mon ami m’a parlé de cette chose qui se passait à Washington, appelée United States Digital Service. Mais USDS n’avait qu’un an et n’avait pas encore beaucoup de processus. J’ai donc regardé le site Web et je me suis dit que je ne savais pas ce que c’était. Et je ne sais pas ce qu’ils font. Mais je me suis dit que mon contrat allait être renouvelé à l’ONU. Alors peut-être que je postule, ils me rappellent. J’ai quelques entretiens, je vais comprendre ce qu’ils font à partir des entretiens. Et peut-être, peut-être que j’obtiens une, une offre concurrente et je l’utilise comme levier dans ma renégociation à l’ONU et puis quatre ou cinq entretiens plus tard avec USDS, je n’avais toujours aucune idée de ce qu’ils faisaient, mais il est devenu très clair pour moi qu’il y avait des gens vraiment, vraiment intéressants, convaincants dans cette, dans cette organisation. Et il y avait aussi des problèmes vraiment

[00:05:00] intéressants et convaincants avec de très grands systèmes anciens. J’ai donc passé environ trois ans et demi à l’USDS, ce qui est à peu près le maximum. Je pense que les limites du mandat y sont de quatre ans. Et ce fut une expérience incroyable de travailler avec des systèmes aussi grands et aussi vieux. Et l’une des choses dont j’ai le plus profité, c’est de réaliser que j’avais toutes ces compétences que je n’avais pas réalisées. Certaines d’entre elles étaient techniques, comme savoir comment les vieux systèmes fonctionnaient, mais la grande majorité de ces compétences cachées étaient en fait plus en ligne avec ces principes de science organisationnelle.

[00:05:41] Par exemple, je me souviens d’être arrivé très tôt à l’USDS et d’avoir discuté avec un collègue dont je reprenais le projet. Il m’a dit qu’il faisait le tour des gens du gouvernement, et nous sommes au début du mois d’octobre, il est allé voir les gens du gouvernement et leur a présenté le cloud et les économies qu’ils allaient réaliser. Et j’étais juste comme, attendez une 

[00:06:00] minute. Vous parlez à des fonctionnaires d’économiser de l’argent en octobre. Et il était comme, ouais. J’étais comme, ce n’est pas, ce n’est pas le discours que vous voulez leur dire sur le cloud, comme, il y a, ce sont les choses que vous voulez

[00:06:11] Alistair Croll : [00:06:11] Novembre va être un mois terrible pour vous. 

[00:06:12] Marianne Bellotti : [00:06:12] Il était comme, pourquoi ? J’ai dit, parce que c’est la fin de l’année fiscale et ils sont sur les principes généraux de comptabilité pour le secteur public. S’ils ne dépensent pas leur argent, ils le perdent l’année suivante. C’est comme si personne ne se souciait d’économiser de l’argent en septembre et octobre. Comme si les gens voulaient mettre le feu à l’argent. C’est comme si tout ce qui reste dans leur budget, ils veulent le brûler pour que leur budget ne soit pas réduit l’année suivante. C’est comme si vous ne pouviez pas vous promener et dire aux DSI qu’ils vont vous faire économiser de l’argent en octobre. Et c’était comme, des choses comme ça, comme des choses que je venais d’une perspective différente et j’avais un ensemble différent de comme des principes que je naviguais en quelque sorte de ce monde, et c’était super précieux et je n’avais même pas considéré ou apprécié cela. 

[00:06:57] Alistair Croll : [00:06:57] Donc c’est une des choses que j’ai retenu du livre c’est que 

[00:07:00] le contexte est si important et il faut laisser vos ingénieurs réaliser le contexte avec un système. Et quand vous parlez de technologie, le contexte est le suivi et c’est, c’est être capable de vraiment comprendre à quoi ressemblait le monde quand ça a été écrit ? Y avait-il une sorte d’ingénieur qui voulait faire avancer sa carrière parce que Java était la nouvelle chose à l’époque et c’est pourquoi cette chose est écrite en Java. Vous savez, quelles étaient les incitations financières ? Combien de temps pensaient-ils que le système serait en place et, par conséquent, quelle date de stockage ont-ils utilisé ? Une grande partie de cela est de prendre le temps d’être, je sais que vous êtes un anthropologue, c’est presque comme l’archéologie et d’y aller et d’être la Jane Goodall qui vit avec l’ordinateur central jusqu’à ce que vous le compreniez, d’accord. Et ce contexte peut être une incitation. Comme vous l’avez dit, comme les budgets des années fiscales, mais ça peut aussi être le contexte, comme si quelqu’un voulait présenter à une conférence ou si une grande partie de ce que j’ai retenu de ce livre est que nous ne prenons pas le temps de permettre à nos travailleurs techniques d’obtenir le 

[00:08:00] contexte nécessaire pour prendre des décisions sages dans le contexte du monde, dans lequel ces systèmes hérités ont été créés. Ouais. 

[00:08:07] Marianne Bellotti : [00:08:07] Je pense que souvent les gens observent mon travail de l’extérieur et disent : « Oh, vous avez de très bonnes compétences sociales ». Et je suis comme, Eh bien, je vous remercie. Mais ce n’est pas tout à fait vrai, non ?

[00:08:18] Ce n’est pas, ce ne sont pas les compétences sociales qui font la différence. C’est le fait de penser aux choses en termes de systèmes, non ? Pas des systèmes techniques, mais des systèmes humains et comme, comment toutes ces personnes sont-elles motivées et comment ces motivations entrent-elles en conflit ? Et comme, quelles sont les règles et les règlements qui sont en jeu ici ? Et ce n’est pas une question de compétences sociales. C’est juste un ensemble de compétences que l’on doit apprendre à faire et que l’on sait qu’il faut faire en arrivant. Et donc ma principale motivation pour écrire ce livre est que c’est vrai quel que soit l’âge du système, comme je construis des systèmes tout neufs maintenant. Et beaucoup de ces principes sont toujours vrais, n’est-ce pas ? Nous avons toujours affaire à des groupes de personnes, nous avons toujours affaire à ce genre de normes culturelles au sein de l’organisation, aux incitations et à la façon dont elles entrent en conflit les unes avec les autres. J’ai donc pensé que ce qui serait vraiment intéressant, c’est d’écrire un livre qui soit un livre technique, mais pas si technique, qu’il soit inaccessible aux personnes qui se sont rencontrées. Cela fait peut-être quelques années qu’ils n’ont pas mis les mains sur un clavier ou qu’ils ont un rôle complémentaire, pas directement lié à l’informatique, mais suffisamment technique pour entrer dans l’esprit des ingénieurs en logiciel. Mais son objectif premier n’est pas vraiment de nature technique. Je ne pense pas qu’il y ait vraiment de code dans ce livre. Il y a quelques diagrammes et il y a un peu de jargon technique, mais j’ai essayé très fort de le rendre accessible aux lecteurs ayant des connaissances techniques, mais pas nécessairement aux lecteurs ingénieurs en logiciel, précisément pour cette raison, parce que je pense que votre succès ou votre échec dans n’importe quel projet technique dépend plus de la façon dont vous alignez les incitations dans votre organisation que de la technologie que vous choisissez ou des brillants ingénieurs que vous embauchez pour le construire. Et c’est quelque chose que tout le monde dans l’organisation doit comprendre. 

[00:10:05] Alistair Croll : [00:10:05] Donc le terme Kill It with Fire. Je veux dire, j’ai entendu ça comme un mème, je l’ai vu plusieurs fois. Je pense que c’est passé dans les Simpsons, mais votre livre n’a pas dit en fait qu’il faut tuer les systèmes par le feu. En fait, c’est plutôt le contraire. Pouvez-vous expliquer, tout d’abord il y a cette, cette idée fausse, je pense que cela apparaît très clairement dans le livre que beaucoup de gens croient que la construction d’un produit technologique se termine lorsque vous le lancez et vous avez cette ligne à la fin du livre et tout au long, je suis comme, Oh, je parie que vous, elle dit cela et vous avez cette ligne dans le dernier chapitre. Vous dites, arrêtez de dire que le site web est terminé. C’est vrai. Et je pense que la simplicité nous manque, comme si c’était un objet tangible dont je n’avais pas à me soucier. Je peux passer à d’autres choses qui restent, ce qui est une idée très atomique que nous construisons une chose et puis il se décompose au fil du temps, mais il vit. C’est un être vivant et par conséquent, vous devriez le tuer avec du feu parce que sinon, il va juste vous faire vivre. C’est vrai.

[00:11:00] Mais vous ne pensez pas réellement que nous devrions tuer ces choses. En fait, je pense que l’une de vos grandes prescriptions est : « ne réécrivez pas les choses à partir de zéro parce que vous allez presque certainement mourir ». Donc le titre est une contradiction. Était-ce intentionnel ? 

[00:11:11] Marianne Bellotti : [00:11:11] Oui, en quelque sorte. Je pense que le titre et la couverture, qui pour les gens qui ne l’ont pas vu est un feu de poubelle, étaient très délibérés. Pour moi, c’était une sorte de, eh bien, commençons par les gens à qui je veux parler, commençons à leur niveau et, par exemple, quelles sont leurs hypothèses ? C’est vrai. Et donc, la chose que, le retour que je recevais le plus souvent des ingénieurs en logiciel, lorsque nous commencions à travailler ensemble, c’est que c’est affreux et frustrant et dégoûtant, et comme une mauvaise utilisation de mon temps. Et je ne vais pas m’améliorer en tant qu’ingénieur en particulier, il y avait une grande inquiétude parmi les ingénieurs qui entraient à l’USDS ou dans n’importe quel service fédéral étranger que leurs compétences techniques allaient s’atrophier à cause de ce travail et qu’ils n’allaient plus pouvoir être embauchés après parce qu’ils auraient perdu leur

[00:12:00] doigt sur le pouls de la technologie moderne, ce que je trouvais vraiment stupide, n’est-ce pas ? Comme, parce que j’ai toujours eu l’impression que j’ai appris beaucoup plus sur la technologie que ce que j’aurais jamais appris en tant qu’ingénieur logiciel normal pour le faire. Donc, je voulais juste commencer au niveau de l’adresse, de la reconnaissance, de la sorte de clin d’œil et de hochement de tête à ces hypothèses de base sous-jacentes des personnes que j’essaie d’atteindre, qui sont les gens qui pensent : « Je ne ferai jamais de travail de modernisation parce que le travail de modernisation est horrible et comme, je vais juste l’éviter ». Et puis je les attire vers ce que je décrirais comme la beauté du travail de modernisation. Comme je suis tombé amoureux de ça parce que je trouve ça comme une réflexion intéressante et l’exploration d’un groupe de personnes plutôt qu’un ensemble de code. C’est vrai. C’est comme si les gens pensaient que le code et la technologie étaient basés sur la science des maths et donc complètement et totalement objectifs, dépouillés de toute culture. Et ce n’est fondamentalement pas

[00:13:00] vrai, non ? C’est un artefact de la culture, de la même façon que la poésie, la musique ou l’art, qui implique simplement des ordinateurs et qui est exécuté dans un but particulier.

[00:13:12] Alistair Croll : [00:13:12] Donc dans le gouvernement, nous avons cette bataille de la culture contre la technologie, que vous avez très bien décrite et c’est vrai dans le secteur privé et le secteur public. Bien que je pense que dans le secteur privé, il y a plus de sens de, je le veux, je veux faire mes preuves afin d’obtenir un meilleur emploi, alors qu’il y a plus d’aversion au risque et soyons prudents dans le gouvernement, mais dans le gouvernement, il y a ce problème de sentiment public contre la priorité. J’ai donc parlé à un certain nombre de personnes au sein du gouvernement au fil des ans, depuis que nous avons lancé FWD50, qui m’ont dit qu’elles avaient un budget. Et parfois ce budget est si important qu’il représente une somme d’argent ruineuse. C’est vrai. Et vous savez exactement ce que je veux dire par là, c’est que vous avez tellement d’argent que vous vous croyez invincible ou que vous n’avez pas besoin de établir des priorités. Vous savez, le, le facteur de déclenchement à propos de l’argent est que si vous avez un petit

[00:14:00] peu, vous devez être judicieux. Si vous en avez beaucoup, vous pouvez être imprudent, mais le problème des montants ruineux dans le gouvernement, je pense, est amplifié par le fait que l’argent est une indication de la volonté politique. Donc si votre gouvernement dit, nous devons régler le problème du changement climatique, nous allons consacrer un milliard de dollars au changement climatique et vous deviez dire, non, non, non, un milliard de dollars ne fera jamais rien. Donnez-moi cent millions et nous ferons quelque chose ou quelque chose comme ça. Des chiffres différents. L’année a été marquée par le rejet des leviers de pouvoir permettant d’indiquer aux électeurs que vous êtes sérieux quant à vos promesses ou à vos programmes politiques.

[00:14:34] Comment gérez-vous un épisode ruiné, comme vous ne voulez pas dire non à un épisode ruiné à cause de l’argent, mais cela vous ruinera. Comment équilibrer ce désir de démontrer une volonté politique avec l’efficacité ? 

Marianne Bellotti : [00:14:44] Ouais, je veux dire, c’est de l’argent et c’est aussi du temps, non ? Donc je, comme le recensement américain, chaque décennale, chaque, donc tous les 10 ans a une sorte, des difficultés avec leur technologie. Soyons, soyons

[00:15:00] généreux ici. Et je pense que cela a en grande partie à voir avec le fait qu’ils ont beaucoup d’argent à dépenser parce que le recensement décennal est extrêmement important, mais cela a aussi à voir avec le fait qu’ils ont 10 ans pour le faire. C’est vrai. Et donc j’ai discuté avec eux de leur technologie 2020 et j’ai cherché à les aider. Et ils m’ont dit, pourquoi ne pas nous aider pour 2030 ? Je suis au courant, attendez une seconde. Pourquoi faisons-nous semblant que rien ne changera en 10 ans de technologie ? C’est ça ? Comme la technologie que nous construisons est généralement dépassée dans les six à trois, comme trois à six mois, non ? 

[00:15:33] Alistair Croll : [00:15:33] La durée de vie d’un téléphone de nos jours est de quatre ans.

[00:15:37] Marianne Bellotti : [00:15:37] Ouais. C’est comme cette idée que nous allons faire ça, ça, notre travail d’architecture critique en 2020 pour 2030. C’est comme quoi ? Comme, vous ne pouvez pas penser aux choses de cette façon, mais ils sont incités à penser aux choses de cette façon, parce que c’est une bonne gouvernance, non ? Comme si vous alliez à vos, vos auditeurs et au Congrès et aux autorités de surveillance et si vous disiez, Dieu, nous faisons toute cette planification

[00:16:00] pour 2030, ça semble vraiment bien. Et c’est la même chose avec l’argent. Si vous avez un bon budget derrière les gens, prenez-le au sérieux. Je connais un ami qui était au DHS, qui m’a dit que comme chaque projet, chaque petit projet arrive à 5 millions de dollars parce qu’il est inférieur à 5 millions de dollars, personne ne le prend au sérieux. Donc c’est le minimum qui doit être atteint, ce qui est ridicule. Mais comme, comme pour garder un programme efficace dans ce genre d’environnement, je dirais que, comme, quand il s’agit de votre réel sur le terrain ingénieurs en logiciel, je ne pense pas qu’ils ont beaucoup de visibilité sur le budget, non ? Comme j’ai travaillé dans des startups qui ont beaucoup, beaucoup d’argent et vous le sentez comme, parce que l’argent est juste jeté autour. Mais au gouvernement, en général, on n’installe pas de barils dans la salle de repos ou autre. Il n’y a pas de fêtes chics ou de choses comme ça. La conscience qu’ont les gens de la quantité d’argent qui se trouve réellement dans leurs coffres est beaucoup, beaucoup moins importante que dans le secteur privé. Et donc je pense que vous pouvez en quelque sorte tirer parti 

[00:17:00] de cela. Vous pouvez profiter de ce fait et définir votre plan comme si vous n’aviez pas tout cet argent et comme si vous n’aviez pas tout ce temps et faire en sorte que les choses restent structurées. Donc vraiment au niveau de la gestion, c’est là que le fardeau est de garder cette conscience en échec.

[00:17:16] Alistair Croll : [00:17:16] Puisque vous parlez du secteur privé et public. L’année dernière, j’ai eu une conversation fantastique sur FWDThinking avec Kathy Pham, Katherine Benjamin et Ayushi Roy, et elles ont toutes une expérience en gestion de produit et des réflexions sur la gestion de produit dans le secteur public. Et moi, je suis un Product Manager du secteur privé. L’une des grandes différences est que dans le secteur privé, vous construisez en quelque sorte pour le marché cible qui a le plus d’argent et qui a les mêmes besoins, alors que dans le secteur public, vous construisez pour le marché le plus large possible, souvent pour les marges, parce qu’alors le milieu sera servi. Et donc le défi, je suppose, est que vous devez aller parler à tous ceux qui peuvent dire non, et c’est un, vous savez, cela peut conduire à cette 

sorte de consensus et, et

 [00:18:00] de paralysie de l’analyse qui effraie beaucoup de gens qui essaient de passer du secteur privé au service public. Il y a tellement de différences. Avez-vous des expériences avec des personnes qui ont été amenées de, vous savez, sevrées dans le monde des startups ou amenées de, de grandes entreprises qui doivent ensuite se recalibrer pour le secteur public, avec les nouvelles pénuries et abondances ?

[00:18:20] Marianne Bellotti : [00:18:20] Oui. Et je pense que le fait d’apprécier le fait qu’il s’agit d’un environnement différent et que l’exposition à un environnement différent vous est bénéfique en fin de compte est un élément clé pour traverser cette période, n’est-ce pas ? Comme les gens qui ont des problèmes quand ils pensent aux choses en termes de, eh bien, ma façon de faire est juste meilleure. Alors pourquoi ne pas le faire à ma façon ? Et, et quand vous réalisez qu’il y a plusieurs chemins vers le centre et qu’il y a vraiment des préoccupations légitimes avec certaines des façons dont les choses sont configurées, cela vous aide à apprendre quels sont ces avantages. Et ça, ça, ça approfondit votre compréhension du contexte dans lequel la technologie fonctionne.

[00:19:00] Par exemple, il y a un projet sur lequel j’ai travaillé au début de ma carrière à l’USDS qui concernait le renouvellement des prêts étudiants. Le département de l’éducation faisait remplir aux gens le même formulaire chaque année pour renouveler leurs prêts étudiants. Et si vous oubliez une année, vous n’obtenez pas vos prêts étudiants cette année-là, n’est-ce pas ? Ce n’était pas comme si j’allais faire un diplôme de quatre ans, je remplissais ce formulaire une fois et je recevais mes prêts pour les quatre années. La raison principale pour laquelle cela était nécessaire est que vous deviez autoriser le département de l’éducation à demander vos données fiscales à l’IRS. Et il y a eu cette énorme bataille interne au sein de l’USDS à propos de cette idée, du genre, pourquoi ne pouvons-nous pas simplement les autoriser pour plusieurs années ? L’IRS reçoit vos données, les envoie au département de l’éducation, et le département de l’éducation dit automatiquement : « OK, voici ce que vous allez recevoir en prêts étudiants pour cette année ». Pourquoi ne pouvons-nous pas faire une autorisation pluriannuelle et, et il y a des

[00:20:00] avantages et des inconvénients des deux côtés, mais fondamentalement, cela revient à dire, oui, c’est probablement inefficace de le faire de cette façon, mais aussi, voulez-vous vraiment que l’IRS se sente à l’aise pour envoyer vos données financières privées à d’autres agences gouvernementales ? La raison pour laquelle ce rôle existe est que l’administration de Richard Nixon a abusé de l’IRS et des données dont il disposait à son avantage politique.

[00:20:23] Alistair Croll : [00:20:23] Alors, est-ce que ça semble être le cas ? Tous ces systèmes, il y a de très bonnes raisons pour que toutes ces choses soient comme elles sont, mais ce sont des aiguilles si fines que vous finissez par devoir les réenfiler à chaque fois. Et, et encore, c’est presque comme s’il y avait, ils ont accumulé une dette législative au lieu d’une dette technique. Il faudrait qu’il y ait un truc derrière qui dise : « Hé, c’est comme ça que vous autorisez annuellement toutes vos informations publiques à être communiquées et à être notifié quand quelqu’un les regarde ». Oui, ça résoudrait le problème. C’est vrai. Mais, mais c’est, c’est comme la dette législative ou la dette technique. C’est tellement important et comme vous le dites dans le livre : quand une équipe jaune est appelée et nous allons parler d’une équipe jaune dans une minute, c’est parce que ça couvre plusieurs départements et ça couvre l’IRS et le département de l’éducation et donc vous avez besoin d’une équipe législative jaune pour y aller. Nous devons repenser la façon dont le partage de l’information se fait avec le consentement éclairé et l’effort minimum au nom des citoyens, mais il n’y a pas de version gouvernementale des lois sur les équipes jaunes. N’est-ce pas ?

Marianne Bellotti : [00:21:22]Nous l’avons fait, nous l’avons fait au niveau de la Maison Blanche parce que le gouvernement américain est très pointilleux sur la séparation des branches. J’avais un ami. Il vérifiait les sites web publics des gens pour une vulnérabilité particulière, je ne me souviens plus si c’était Heartbleed ou dessiné ou autre, mais il a trouvé que la, la bibliothèque du Congrès avait une vulnérabilité active sur leur site web. Il leur a donc envoyé un courriel, qui lui a été retourné pour leur demander pourquoi une personne de la Maison-Blanche effectuait des tests de sécurité sur la bibliothèque du Congrès, qui fait partie du pouvoir exécutif. C’est une violation constitutionnelle de la séparation des pouvoirs. Et c’est comme si rien ne s’était passé parce que

[00:22:00] finalement les gens apprécient que quelqu’un essaie d’améliorer leur sécurité, mais c’était un email très amusant.

[00:22:06] Alistair Croll : [00:22:06] Ouais. Cela ressemble à un grand exemple de séparation. Vous savez, le, l’exécutif, le gouvernement tripartite, sur lequel je pense que le monde entier a suivi un cours intensif l’année dernière. Il y a toutes sortes de contrôles et d’équilibres intéressants. 

[00:22:16] Marianne Bellotti : [00:22:16] Pour en revenir à la gestion de produit pour une minute ici, je dirais que la différence fondamentale à comprendre entre le secteur privé et le gouvernement est que parce que le gouvernement ne cherche pas à faire du profit, vous devez ajuster la façon dont vous, vous itérez, élargissez le marché, d’accord ? Donc généralement dans le secteur privé, les gens pensent comme, quelle est la plus grande, la plus rentable des segmentations de personnes qui pourraient utiliser cette chose, construisons-la spécifiquement pour eux pour obtenir tous, tous les problèmes dans l’interface utilisateur et puis passer à un autre groupe et un autre groupe et un autre groupe. Je trouve que dans le gouvernement, il est souvent bénéfique de penser en termes de personnes qui ont le plus grand besoin, d’accord. Nous avons donc eu cette énorme discussion sur la conformité 508, [00:23:00] qui est la norme d’accessibilité des États-Unis. Les lecteurs d’écran peuvent-ils interagir avec votre site Web de manière appropriée ? Tous ces outils pour les personnes sourdes, aveugles, quoi, comment, etc. et beaucoup d’ingénieurs en logiciel du secteur privé disaient, eh bien, nous verrons cela plus tard. Faisons-le pour la personne normale. Et ensuite, tous ces cas délicats, on les fera plus tard et j’ai l’impression qu’il est plus important pour nous de s’adresser à ces groupes de personnes d’abord et ensuite d’étendre nos capacités à un groupe plus normal, en grande partie parce que c’est un service gouvernemental qui est le plus semblable.

[00:23:37]Alistair Croll : [00:23:37] Et le support que vous obtenez pour le groupe normal, normal entre guillemets, vous obtenez le support pour le marché de masse par défaut, si vous concevez pour les bords, ce qui est juste une différence philosophique. Pas vrai ? Donc, j’ai une tonne de questions et je veux entrer dans la substance ici. Vous avez beaucoup mentionné l’entropie. Et je pense que pour, pas tellement les technologues, parce qu’ils

[00:24:00] comprennent les systèmes et ainsi de suite dans la plupart des cas, mais les cadres ont besoin d’une bien meilleure compréhension des concepts comme le fait que, vous 

Vous savez, tout système non entretenu se développe et une sorte d’entropie se produit si vous ne maintenez pas les choses, que c’est, que ce genre de systèmes sont en vie et se nourrissent, et vous devez aller et comprendre cela, mais aussi des choses comme la pensée de conception, les incitations, la théorie des jeux, il y a tellement de sortes de composantes d’arts libéraux à la gestion de la technologie. Si vous aviez un mois pour former un sous-ministre ou l’équivalent d’un autre gouvernement sur la façon de gérer leur feuille de route technologique, que leur diriez-vous de faire ou de

[00:24:41] de lire autre chose que votre livre, en termes de pensée conceptuelle, d’incitations, de théorie des jeux et toutes ces choses. Quelles sont les choses non-technologiques, parce que la plupart d’entre eux disent, Oh, je vais juste aller apprendre à coder, ou je vais apprendre agile ou autre. Quelles sont les choses qui pourraient les aider, les aider à vraiment [00:25:00] regarder les problèmes d’une nouvelle manière ?

[00:25:01] Marianne Bellotti : [00:25:01] Bien, ce que je pense de ce que je pense être vraiment intéressant à propos d’agile, c’est que tout le monde semble prendre le cadre de celui-ci et manquer complètement la philosophie derrière. C’est vrai. Et, et l’agile c’est de s’assurer que les gens qui mettent en œuvre la technologie sont habilités à prendre des décisions à ce sujet et à faire des expériences et puis si ces expériences échouent, comme pour les enlever et comme recommencer. C’est vrai. Et, et les gens ont tendance à ignorer cette partie et à juste dire, eh bien, nous avons notre maître de mêlée et nous avons nos sprints et nous avons comme, juste prendre tous les accessoires de celui-ci. 

[00:25:35] Exactement. C’est comme si les gens aiment leurs, leurs cadres et leur structure et ils ignorent complètement ce que nous essayons d’accomplir avec Agile. Et donc comme la, la, la chose qui est la plus importante pour moi pour quelqu’un de haut niveau à comprendre est ce que vos gens qui font l’implémentation peuvent réellement faire, n’est-ce pas ? Qu’est-ce qu’ils sont réellement habilités à faire ? Et s’il y a un problème dans le système, à qui peuvent-ils s’adresser ? Comme, comment peuvent-ils escalader ? Comment le problème est-il résolu ? Parce que c’est la première cause de dysfonctionnement dans n’importe quel système, c’est que les gens qui sont sur le terrain n’ont pas le pouvoir d’y apporter des changements. Ils ne sont pas habilités à résoudre un conflit. Et s’il y a escalade, ils sont punis pour cette escalade. Par exemple, ce que j’ai fait de plus efficace, c’est d’aller au niveau de l’ingénierie, de comprendre qu’il y avait un problème et d’escalader pour eux d’une manière qui les protège, qui les garde anonymes. Ainsi, il n’y avait pas de retour de bâton pour eux plus tard. Et c’est vraiment important. C’est un principe que je pense que le secteur privé n’est pas parfait, mais qu’il fait beaucoup mieux que le gouvernement – les gens du gouvernement gravitent généralement autour de cette idée de, eh bien, si nous rendons la punition vraiment mauvaise, alors évidemment les gens feront, feront la bonne chose. Et c’est exactement le contraire. Comme nous savons que l’exact opposé est vrai. 

[00:26:59] [00:27:00] Alistair Croll : [00:26:59] Une des choses dont vous parlez dans le livre est cette idée de briser les monolithes, alors tout d’abord, pouvez-vous expliquer rapidement ce qu’est un monolithe en dehors de 2001 ? 

[00:27:09] Marianne Bellotti : [00:27:09] Oui. Un monolithe c’est un programme informatique qui combine plusieurs fonctionnalités dans une seule unité opérationnelle, une seule base de code, typiquement une seule application.

[00:27:26] Alistair Croll : [00:27:26] Donc. Vous dites que parfois une chose peut être une fonction et qu’il est mauvais de prendre une chose qui est une fonction et d’essayer d’en faire un service. Et puis vous 

que parfois les monolithes sont trop gros et qu’il faut alors les diviser en services. Il semble que dans le livre, cette idée de comprendre ce qu’est une fonction, ce qu’est un service et ce qu’est un monolithe et quand ces trois éléments sont importants, est vraiment un vernaculaire ou quelque chose comme ça. Y a-t-il des résultats, des rasoirs pour savoir ce qui doit être une fonction, ce qui doit être un service et ce qui doit être un monolithe ?

[00:27:57] Marianne Bellotti : [00:27:57] Oui. Donc je dirais que les premières personnes sont vraiment effrayées [00:28:00] par les monolithes pour une raison, je pense inutilement effrayées par les monolithes. Ils ont une mauvaise réputation ? Et personne ne veut construire le modèle avec comme, c’est une honte si vous finissez par construire un monolithe, mais je pense que c’est juste en fait la façon dont le code évolue, non ? Quand, quand il y a une petite fonctionnalité que vous voulez tester, vous avez tendance à ne pas construire des services séparés pour eux, vous avez tendance à juste les attacher à un endroit où ils semblent logiquement s’adapter. Et puis au fur et à mesure que vous les construisez et qu’elles évoluent, elles grandissent et grandissent. Et soudain, vous avez une sorte de structure monolithique. Donc, ce que je souligne est cette idée que, que vous ne pouvez pas venir dans n’importe quel, n’importe quel projet technologique en pensant que je vais construire de cette façon, et qu’il n’y aura jamais de changement, n’est-ce pas ? Vous ne pouvez pas, vous devez changer votre mode d’échec pour qu’au bout de cinq ans maintenant, pour que vous réalisiez que nous devons réarchitecturer ça ou le casser, ce n’est pas un échec. Dans de nombreux cas, c’est un succès parce que cela signifie que les gens l’utilisent. Donc vous avez construit la bonne chose et ça a été un succès. La, la norme que j’utilise toujours pour les gens en termes de savoir si oui ou non ils devraient être en mesure de construire des services séparés pour [00:29:00] quelque chose, ou ils devraient construire un modèle de pour l’instant et le décomposer en services séparés est vraiment sur la maintenance en particulier, j’utilise les rotations d’astreinte comme référence parce que tout d’abord, nous devrions être d’astreinte pour les choses que nous exécutons en production. Mais c’est aussi, je pense, un jeu de chiffres vraiment tangible très rapidement quand on y pense de cette façon. Donc, pour les personnes qui ne sont pas familières, une rotation d’astreinte signifie essentiellement que nous prenons un ensemble d’ingénieurs logiciels et que nous leur donnons un pager au sens propre, mais maintenant nous avons ce truc appelé PagerDuty qui est sur nos téléphones. Donc on charge l’application sur notre téléphone et on dit, ok, Marianne pour cette semaine tu es responsable de t’assurer que ce service est en ligne et fonctionne bien. Donc, dès que notre système de surveillance nous dit qu’il y a quelque chose qui se passe avec ce service ou qu’il est en panne, vous allez être bipée. Si cela se produit à trois heures du matin, vous devez vous lever, vous connecter à votre ordinateur, vous connecter en SSH et réparer. Si cela se produit dans le Workday,

[00:30:00] alors, vous savez, c’est le même processus, mais vous êtes responsable du système 24 heures par jour pendant généralement une semaine. C’est vrai. Et puis à la fin de cette semaine, je passe la main à la personne suivante dans la rotation d’astreinte. Nous passons par là. Et de façon réaliste, je n’aime pas faire des rotations d’astreinte avec moins de six personnes. Et je n’aime pas les gérer avec moins de six personnes parce que ce que j’aime avoir, c’est essentiellement deux rotations différentes. La première est la rotation réelle, et la seconde est une liste de secours, de sorte que si Dieu vous en préserve, votre téléphone n’a plus de batterie, ou si, pour une raison quelconque, vous n’êtes pas disponible sur votre, sur appel, nous, nous n’attendons pas éternellement avec le service en panne. Nous payons juste la personne qui est votre sauvegarde. Et donc six est le nombre minimum que nous pouvons faire sans que les gens soient sur appel tout le temps et s’épuisent. Et donc, si on y pense de cette façon, on se demande combien de personnes on a ? Combien de rotations de six personnes pouvons-nous faire sans épuiser les gens, sans les surcharger avec tout ce travail supplémentaire. Et nous utiliserons cela comme point de référence pour savoir combien de services séparés nous pouvons gérer. Donc si nous sommes une très petite équipe et que nous pouvons vraiment seulement gérer une rotation de six personnes sur appel que nous devrions construire un monolithe. C’est vrai. Mais si nous sommes une plus grande équipe et que nous ne pouvons pas gérer plus d’une rotation de personnes sur appel, ok. Donc maintenant nous avons deux services ou trois services. On peut y penser de cette façon. Et je trouve que c’est une façon très efficace de penser à ce qu’est l’architecture pour l’instant pour la taille de l’équipe que nous avons pour les ressources que nous avons. Et puis au fur et à mesure que nous nous développons. Par exemple, quand est-ce qu’on pense à la casser ? Parce que ce que beaucoup de gens font quand ils, quand ils entrent dans le monde des microservices, c’est qu’ils construisent tout un tas de petits services qu’ils ne maintiennent jamais. Et ce n’est pas mieux que de construire un modèle. 

[00:31:48] Alistair Croll : [00:31:48] Donc ça, ça s’intègre parfaitement dans ma prochaine question qui concerne les microservices. J’ai expliqué l’idée d’un très bon microservice atomique comme le système de stockage S3 d’Amazon [00:32:00], par exemple, mais c’est vrai pour Zephyr, ou tout autre modèle de stockage distribué partagé. Et tout ce qu’il fait c’est deux choses. Si je lui donne une URL, il me donne un objet, comme l’image que j’ai stockée ici. Et si je lui donne un objet, il me donne votre URL, qui est la façon dont j’obtiens cette image plus tard. Et tout le reste, ce sont des détails, non ? Je dis, voici un film. Il me dit, voici l’URL de ce film. Je vais, voici l’URL du film. Il me joue dans le film. Comme si c’était tout ce qu’il faisait. Et Bezos parle d’une équipe de deux pizzas, ce qui correspond à peu près à la taille de quelques rotations, en fonction de l’avidité de vos ingénieurs. Mais il semble que ces choses soient liées, qu’il y ait cette taille idéale pour un service atomique. Mais savoir ce que sont ces services atomiques est essentiel. Je sais qu’au Royaume-Uni, le GDS essaie de construire des services de base comme publier et s’abonner ou des plateformes de notification ou un système de formulaires, vous savez, des blocs de base qu’une petite équipe peut rendre absolument résilients et ensuite avoir un contrat très clairement défini

[00:33:00] entre eux et les autres services. Et si j’ai retenu une leçon pour la route vers une gestion durable à long terme de l’héritage. Il s’agit de prendre vos monolithes, de les décomposer en ces services atomiques qui peuvent être maintenus par une équipe de deux pizzas avec une petite rotation sur appel, de reconnaître qu’ils vont continuer à vivre pour toujours et de définir de très bons contrats entre ces services afin que vous puissiez réparer n’importe quelle partie, indépendamment des autres parties pour toujours. Et c’est un peu comme le Nirvana qui n’arrivera jamais, mais c’est une aspiration. Alors, est-ce que j’ai bien compris ? Tout d’abord.

[00:33:36]Marianne Bellotti : [00:33:36] Donc je pense que c’est, c’est le consensus général. C’est vrai. Et je ne pense pas du tout que ce soit une mauvaise stratégie, mais ce que je souligne, c’est qu’il faut faire des compromis. Comme essentiellement nous parlons d’efficacité, mais oui, si vous avez d’abord, si vous avez l’adéquation produit-marché et vous savez ce que vous construisez et vous savez quels sont les différents services dont vous avez besoin, et vous pouvez les séparer dans ces services atomiques, c’est une façon plus [00:34:00] efficace de dépenser vos ressources techniques que d’autres formes d’architecture. Mais la réalité est que parfois il est à votre avantage de faire fonctionner les choses de manière inefficace, parce qu’il y a d’autres facteurs en jeu. Et donc les gens vont se dire, eh bien, je dois construire des services parce que j’ai besoin d’évoluer. Vous pouvez faire évoluer un monolithe. C’est possible de faire évoluer des monolithes. Je peux citer des entreprises qui font des milliards de transactions par seconde, qui sont fondamentalement juste un monolithe, à la fin de la journée, 

[00:34:32] Alistair Croll : [00:34:32] Comme Google. Ouais.

[00:34:34] Marianne Bellotti : [00:34:34] Google a le modèle à la, juste la base du code. C’est vrai. Mais c’est tiré vers des services séparés lors du déploiement. Donc ça, c’est un peu comme un C’est un scénario intéressant, mais comme l’industrie dont je viens de sortir, l’identité en tant que service, Octa est un monolithe, Azure est un monolithe. Comme ces entreprises, elles, elles sont des modélistes de l’échelle, le truc c’est que, c’est que ça va vous coûter plus cher. C’est vrai. Et donc c’est

[00:35:00] un business. Le compromis comme le montant du coût qu’il faudra pour mettre à l’échelle ce monolithe si pour vos pics de transactions, est-ce que ça vaut les autres facteurs comme la rupture en microservices. Et donc je pense que c’est la clé avec les technologies, comprendre qu’il n’y a comme une, une règle d’or. Il n’y a pas de balles d’argent. Il n’y a pas une architecture ou une technologie qui va vous mener dans la bonne direction cent pour cent du temps, vous devez vraiment évaluer équitablement le contexte dans lequel vous mettez cette technologie et comment vous l’utilisez. Et puis être honnête sur ce que sont ces lignes droites et pourquoi ils finissent par être le cas que vous pensez à vous-même, comme, wow, comme nous avons un ensemble de COBOL qui est raisonnablement bien entretenu que nous aimons comprendre dans un mainframe qui vient de, comme, nous venons d’acheter un nouveau d’IBM. And so like that that that that is that that’s what suits us. C’est ce qui va faire le travail pour nous. Et c’est là que nos compromis s’alignent. Et comme, j’embrasse ces choix. Je ne pense pas qu’il y ait

[00:36:00] quelque chose de mal à ça parce qu’au bout du compte, la technologie est un outil. 

[00:36:03] Alistair Croll : [00:36:03] C’est gentil de votre part de mentionner IBM puisque c’est IBM qui l’a organisé. Donc merci beaucoup. Vous aimez manifestement Conway et la loi de Conway. Peux-tu me dire pourquoi la loi de Conway n’est pas une malédiction ? Et ce qu’est la loi de Conway peut-être ? 

[00:36:15] Marianne Bellotti : [00:36:15] Je pense que oui. J’encourage les gens à lire l’article original de Melvin Conway, qui a donné le coup d’envoi de la loi de Conway, parce que tout d’abord, il n’est pas très difficile à lire. Ce n’est pas terriblement long. Et c’est vraiment intéressant. Les gens parlent de la loi de Conway d’une manière très bizarre, comme s’il s’agissait d’une sorte de malédiction, mais en réalité, il s’agit de gens qui conçoivent des technologies basées sur leurs voies de communication. C’est ça ? Donc vous n’améliorez pas l’architecture de votre technologie en déplaçant les cases de l’organigramme sur un diagramme Vizio. Comme si ça n’allait pas immédiatement Conway. Eh bien, ça ne marche pas parce que tu réorganises et ensuite tout le monde, juste pour ton âge, est la

[00:37:00] technologie. Il s’agit de savoir qui parle à qui. Comme, comment ils sont liés les uns aux autres ? Comment font-ils pour se rapporter à différentes personnes et comment se parlent-ils entre eux ? Et ça, c’est un point de vue vraiment critique. Il parle aussi un peu d’incitations. Il dit en gros, Hé, si vous avez cette unité organisationnelle. qui a besoin de justifier son existence. Le moyen le plus facile pour eux de justifier leur existence est de construire la technologie comme si elle était séparée et indique en quelque sorte leur présence dans l’organisation. Donc je pense que la loi de Conway est vraiment un accomplissement fascinant pour moi parce qu’il ne faisait essentiellement que des observations. Et pourtant, elles sont si pertinentes pour la technologie dans tous les différents types d’organisations que j’encourage vraiment les gens à revenir à l’article original et à le lire, qui se trouve sur son site Web. C’est la chose la plus facile au monde. 

[00:37:57] Alistair Croll : [00:37:57] Eh bien, nous allons mettre le lien dans la vidéo pour sûr.

Une

[00:38:00] ou deux autres questions rapides. Je sais que nous sommes presque à court de temps, ce qui est terrible parce que j’ai tellement d’autres questions. Une autre chose qui m’est apparue comme un modèle sous-jacent dans votre livre, en plus de l’entropie et d’autres choses, c’est la création d’une agence que vous devez faire tellement pour que l’équipe ait l’impression d’avoir une agence, en leur donnant toute l’autorité proportionnelle à la responsabilité, même des choses comme, ouais, des conseils de meurtre qui ne sont pas Il ne s’agit pas de les démolir, mais de leur montrer qu’ils sont résistants. Quelle est l’importance de la confiance en soi au sein de l’agence, de l’équipe et que doit faire un leader pour briser un mauvais schéma ? 

Marianne Bellotti : [00:38:34] Ouais, je veux dire, comme traiter avec une équipe qui a été brûlée beaucoup, beaucoup de fois par un mauvais leadership est l’une des choses les plus difficiles à faire. Et il s’agit simplement d’établir la confiance à ce moment-là. Et donc je pense que pour moi, la confiance et l’authenticité, vont de pair. J’ai un léger avantage dans le sens où j’ai une personnalité très unique, une malédiction, comme un

[00:39:00] marin, et je me présente et je suis très informel et désinvolte. Et comme les gens trouvent ça dérangeant parfois, mais quand ils, ils s’y habituent, c’est une plus grande forme de confiance parce que, comme, je ne vais pas être comme eux.

[00:39:13] C’est vrai. Et je vais travailler dur et, et être, mes intentions vont être honnêtes et directes. Je pense que ça marche vraiment bien. J’ai été surpris de l’efficacité de la planche de meurtre. Pour ceux qui ne sont pas familiers et qui n’ont pas encore lu le livre, un murder board est quelque chose que nous faisons plutôt du côté de la politique, surtout si nous avons des gens qui doivent être confirmés par le Sénat, nous rassemblons des gens, un groupe de gens, et nous leur demandons de penser aux pires questions qui pourraient être posées et à la manière la plus agressive de les poser. Et puis nous, nous asseyons la personne qui doit passer par cette expérience, quelle qu’elle soit, et nous la frappons avec ça encore et encore et encore. Et c’est ce qu’on appelle un murder board parce que c’est comme si vos collègues essayaient de vous tuer. [00:40:00] 

[00:40:00] Alistair Croll : [00:40:00] Cela ressemble à quelque chose qui pourrait décoller dans la Vallée comme une forme de candeur radicale rencontrant une intervention thérapeutique extrême. 

[00:40:08] Marianne Bellotti : [00:40:08] Je pense que ça pourrait, je pense que ça pourrait, c’est comme, j’ai juste été exposée à ça comme, comme dans le monde politique et j’ai eu affaire à une équipe qui avait littéralement été comme ils étaient terrifiés. Ils étaient terrifiés à l’idée de faire des choses qu’ils savaient, qu’ils savent faire parce qu’ils, ils, à chaque fois qu’ils échouaient, c’était comme s’ils étaient si critiques pour l’infrastructure du produit que c’était comme s’ils échouaient devant une organisation entière de 500 personnes. Et je me suis dit, d’accord, amenons les meilleurs ingénieurs logiciels que nous avons comme le principal. Ouais. Ingénieurs, les gens qui sont comme la crème de la crème de l’organisation. Et dirigeons ce conseil plus meurtrier parce que tant que nous le faisons, avec la communication du genre, nous faisons ça pour vous rendre plus fort. Et parce que nous croyons en vous et que nous ne vous rabaissons pas ou ne vous pinaillons pas, alors ce que ça devient, c’est une

[00:41:00] expérience où vous êtes essentiellement examinés par les meilleures personnes de l’organisation. Et ça vous donne un peu de, je vais dire un déni plausible, je ne suis pas sûr que ce soit le bon terme, mais ça m’a fait penser que si ça échoue, c’est comme si vous pouviez revenir en arrière et pointer vers ça et dire, eh bien, ouais, comme les, les meilleurs ingénieurs que nous avons embauchés ont regardé ce plan et ont jeté leur pire sur lui et n’ont pas pu trouver de problème avec lui. C’est vrai. Et comme ça, ça donne aux gens.

[00:41:28]Alistair Croll : [00:41:28] Vous avez mentionné que le changement de mentalité des gens de trouver la bonne réponse à venir avec autant de réponses possibles. Et puis cela change les incitations. Et encore une fois, on en revient à la psychologie humaine. J’ai encore trois ou quatre choses que j’aimerais couvrir rapidement si ça ne vous dérange pas de rester dans le coin pour quelques minutes de plus. 

Tout d’abord, le code jaune, et, et, et pour tous ceux qui regardent ça, allez acheter le livre parce qu’il y a tellement de vérité là-dedans, et il y a tellement de choses prescriptives, ce qui est ce que j’aime. Ce n’est pas le genre de soupe au poulet pour l’âme du gouvernement. C’est comme, voici une façon de faire

[00:42:00] ceci. Comme une table ronde sur le meurtre. Je pensais que l’idée du code jaune était géniale et tu as raison. C’est quelque chose que j’ai entendu de la part des employés de X Google, mais très peu de gens parlent de ce que c’est. Vous savez, ils connaissent les singes du chaos et ce genre de choses. Mais le code jaune n’est pas quelque chose qui a été largement expliqué peut-être parce que c’est si facilement abusé si vous ne comprenez pas pourquoi c’est prévu. Ouais. 

Marianne Bellotti : [00:42:20] Et je pense que c’est un peu un truc de geek profond, d’ingénieur logiciel. Et je pense que beaucoup de livres qui sont écrits sur le processus de Google viennent plus de la gestion de produit et du côté commercial des choses que du côté des ingénieurs en logiciel. Mais j’ai trouvé qu’il était immédiatement efficace la première fois que j’ai été soumis à un processus de code jaune. Et je l’ai défendu partout où je suis allé. Il s’agit essentiellement de donner aux gens des privilèges élevés pendant une crise pour un objectif très spécifique. C’est vrai. Et la façon dont la crise est définie, ne doit pas nécessairement être une

[00:43:00] panne. Ça peut juste être comme, je pense, Google l’a utilisé parce que pour la première fois, parce que leurs, leurs chiffres de latence en, en Asie du Sud-Est étaient terribles ou en fait comme juste vraiment, vraiment mauvais. Et ils perdaient, perdaient une énorme quantité de business. Donc ça peut être aussi des choses qui sont critiques pour l’entreprise, mais simplement prendre une petite équipe et lui dire qu’elle est maintenant habilitée. Vous, vous avez le traitement VIP, tout ce dont vous avez besoin, tout ce que vous voulez, les gens doivent arrêter ce qu’ils font et vous le donner immédiatement. Et juste les laisser travailler sur un objectif très spécifique est très efficace. Donc, généralement, c’est la chose que j’essaie définitivement d’apporter aux équipes d’ingénieurs quand ils commencent à travailler avec eux, c’est comme, quelles, quelles sont les normes autour de ça ? Et comme.

[00:43:41] Alistair Croll : [00:43:41] Alors comment, je veux dire, c’est génial de créer les départements de double charge, vous savez, suis-je six pour résoudre un problème particulier, mais vous ne donnez pas à quelqu’un un permis à vie de tuer ou de les laisser voler dans vous savez, des avions de luxe. Il y a une sorte de durée de vie à cela. Comment vous assurez-vous que quelqu’un ne fait pas ça juste parce que son projet est en retard ?

Marianne Bellotti : [00:43:59] Eh bien, donc [00:44:00] je pense que la première chose est d’avoir une bonne culture sur la réponse aux incidents, vous savez, donc les rotations sur appel dont nous avons déjà parlé, mais ensuite, que se passe-t-il quand quelque chose tombe en panne ? Quel est le processus et la procédure pour cela ? Parce que vous pouvez en quelque sorte utiliser le processus de réponse aux incidents comme un modèle pour l’équipe de code jaune. C’est vrai ? Nous ne faisons pas de réponse aux incidents toute la journée, tous les jours. Juste parce que quelque chose est tombé en panne une fois, d’accord. Nous le voulons jusqu’à ce que nous l’ayons remis en marche et que tout le monde ait signé sur le fait que, comme, Eh bien, l’incident réel est terminé. Même si le problème n’est pas résolu à cent pour cent et qu’il nécessite plus, plus de travail.

que, alors le code jaune est beaucoup plus facile à mettre en œuvre de manière responsable que si vous ne le faites pas, si vous vous battez toujours [00:45:00] avec ce genre de processus. 

[00:45:01] Alistair Croll : [00:45:01] Génial. Je sais qu’au Canada nous avons, évidemment, le FWD50 parle au monde entier, nous avons eu, je pense que près de 30 pays ont participé l’année dernière, mais nous voyons beaucoup d’intérêt au Canada. Et nous avons nos propres systèmes hérités, très importants. Le système mondial de gestion des cas, par exemple, GMCs, est un outil énorme que de nombreux ministères utilisent, mais il a connu de nombreux problèmes, des pannes et des choses comme ça. Il y a une longue gouvernance, juste beaucoup d’autres. J’aime votre idée de calcul du risque. Le risque le plus faible est toujours de ne pas faire quelque chose, mais c’est l’héritage qui tend à traiter le futur comme une externalité, n’est-ce pas ? Cette idée que ce n’est pas votre plus grand risque, vous vous faites des illusions parce que vous utilisez l’information qui vous est offerte. Et tout le monde a entendu la vieille foule. Avez-vous essayé de l’éteindre et de le rallumer, mais vous avez une version différente de l’éteindre et de le rallumer pour découvrir où sont vos risques. Pouvez-vous nous en parler ? Ouais. 

[00:45:56] Marianne Bellotti : [00:45:56] Donc, je veux dire, comme avec les systèmes hérités qui n’ont pas vraiment [00:46:00] été maintenus, eh bien, il y a toujours ces services et comme des coins et recoins que personne ne peut vraiment comprendre ce qu’ils font. Et donc, il n’y a qu’une limite à ce que vous pouvez faire avec la recherche et les entretiens avec les gens et comme le nez sur la meule, essayer de comprendre ce que quelque chose fait sans y toucher ou interférer avec. Et, et, vous savez, comme, bien. Mikey Dickerson de l’USDA, très pragmatique et une attitude impitoyable envers ça. Il est du genre, eh bien, si vous l’éteignez, vous découvrirez rapidement ce qu’il fait vraiment bien, d’accord. Et si rien de mal n’arrive et que personne ne vient se plaindre, alors peut-être que nous n’en avions pas besoin. D’accord. En premier lieu. Et quand on parle de ces gros systèmes, le problème de leur maintenance est leur complexité inhérente. Donc à chaque fois que vous pouvez minimiser un peu cette complexité, vous finissez probablement avec un meilleur état que celui que vous aviez avant. Donc vous, vous obtenez les avantages de, si vous n’en aviez pas vraiment besoin, maintenant vous avez minimisé votre complexité. Si vous en aviez vraiment besoin. Maintenant, tu sais ce que fait cette partie du système.

[00:47:00]Alistair Croll : [00:47:00] Et vous, vous faites ce point que, qu’il y a une tentation dans la modernisation d’ajouter de nouvelles fonctionnalités plutôt que de réaliser une parodie de fonctionnalité. Et ce mythe que, comme, parce que vous avez un système qui fonctionne, vous avez un plan pour un nouveau, et puis vous pouvez l’améliorer. Mais vous êtes un fervent défenseur de l’idée de le construire de manière à ce qu’il soit identique à l’autre avant de commencer à ajouter des fonctionnalités, peut-être même moins que le nouveau et ce qu’était le vrai MVP.

[00:47:24] Marianne Bellotti : [00:47:24] Ouais. Eh bien, les anciens systèmes ne sont pas des spécifications pour les nouveaux systèmes et ils sont souvent traités de cette façon. Mais je pense que le secteur privé, du moins la technologie dans son ensemble, est devenu très à l’aise avec l’idée qu’il est impossible de construire un système parfait qui ne tombera jamais en panne. Donc, de notre point de vue, lorsque vous éteignez quelque chose, cela semble imprudent, mais la réalité est que vous devriez avoir le processus et l’infrastructure en place pour gérer une panne colossale sur votre système. Donc ce système est simplement éteint. Ca ne devrait pas être hors norme pour vous d’être préparé à… 

[00:44:35]Mais on n’a pas besoin, comme, tout le monde n’a plus besoin d’être en alerte. Et si vous avez fait ça et qu’il y a beaucoup d’excellents documents de référence sur la façon de gérer les incidents, certains mis en place par Google, certains mis en place par des entreprises qui font de la surveillance comme New Relic ou Honeycomb, des choses comme ça. Vous avez fait ça et vous vous sentez à l’aise avec gérer une panne de ce système. Si vous étiez préparé à gérer une panne sur ce système, vous pouvez l’éteindre quand vous voulez. C’est vrai. 

[00:48:04] Alistair Croll : [00:48:04] Eh bien, vous faites remarquer qu’il y a, j’ai lu les chiffres, il y a comme deux employés à temps plein qui remplacent les disques durs dans un Google typique parce qu’ils sont juste, vous savez, le, le délai entre la défaillance et les disques durs vous allez juste remplacer des petits disques durs. 

[00:48:18] Marianne Bellotti : [00:48:18] Donc ils deviennent très bons dans le remplacement des disques durs. Personne ne remarque quand un disque dur tombe en panne.

[00:48:22] Alistair Croll : [00:48:22] En fait, plusieurs disques durs sont tombés en panne pendant cet appel. C’est vrai. Et c’est comme une chose étonnante à mettre dans votre tête. Comme si, littéralement, pendant cette session, l’Internet n’était pas tombé en panne et que plusieurs disques durs qui étaient probablement impliqués dans la fourniture de ces services étaient tombés en panne. Ok. Dernière question. C’est fascinant et je suis ravi que nous ayons eu autant de temps. Merci beaucoup. Vous parlez de l’utilisation des crises pour produire un changement dont vous pouvez dire, regardez, et souvent ces crises sont liées aux performances et, et elles sont en quelque sorte, vous savez, une question d’opinion, mais dans certains cas, ce sont leurs crises de sécurité qui ne peuvent pas être ignorées. Que fait SolarWinds pour moderniser les systèmes existants et les systèmes gouvernementaux en ce moment ? 

Marianne Bellotti : [00:49:03] SolarWinds est un cas vraiment bizarre. Tout d’abord, pour qu’il y ait une crise et qu’on puisse en tirer profit, il faut être honnête sur le fait qu’il y a une crise et sur les impacts qu’elle a, et je ne suis plus dans le gouvernement donc je n’ai pas une bonne vision de la façon dont SolarWinds est en train de changer la façon dont le gouvernement est configuré, mais j’ai reçu plusieurs courriels ces derniers matins, des communiqués de presse du gouvernement qui déclarent que c’est un succès. Et je suis un peu sceptique à ce sujet parce que j’ai déjà vu des miracles auparavant, mais depuis le début de cette crise jusqu’à l’ampleur de ce que le gouvernement a dû faire, jusqu’à l’endroit où nous sommes maintenant, ce délai est très court pour moi en termes de changement réel au sein du gouvernement. Donc je suis un tout petit peu sceptique. Et ça, ça m’inquiète un peu que nous gaspillions de l’argent en devenant si anxieux sur l’aspect visuel de la chose. L’autre chose qui est intéressante à propos de SolarWinds, c’est que certaines agences qui n’avaient pas de bonnes stratégies de mise à jour et d’application de correctifs ont été sauvées par SolarWinds parce qu’elles ont manqué la vulnérabilité, la, que la vulnérabilité en elle. J’ai donc eu une conversation avec certains de nos amis qui sont encore dans le gouvernement sur le thème :  » Comment s’assurer que la leçon qu’ils retiennent n’est pas qu’il faut arrêter de mettre à jour nos systèmes ou qu’il faut mettre en place ce processus d’audit complètement ridicule en plus de la mise à jour de notre système, parce que c’est comme un événement du cygne noir où le fait de garder votre système bien au-delà vous rend plus vulnérable plutôt que moins. C’est vrai. Donc je pense qu’il y a un, un, un énorme avantage à ce que SolarWinds en tire des leçons et améliore le processus de sécurité et de gouvernement. Je suis optimiste et j’espère qu’il sera utilisé de cette façon, mais il y a plusieurs endroits où il y a un potentiel pour que ça

[00:51:00] tourne mal à cause de ça, parce que le gouvernement pourrait raccourcir les délais et tenter d’améliorer l’image. Et parce que les gens pourraient en fait en retirer. L’idée qu’ils ne devraient pas mettre à jour leurs systèmes. 

[00:51:12] Alistair Croll : [00:51:12] Très fascinant. Alors Marianne, j’ai vraiment, vraiment apprécié ce livre et je lis beaucoup de livres et je ne dis pas simplement que je ne m’attendais pas à ce que ce soit un livre aussi humain. Il y a la technologie, les idées, les fonctions, les services, les monolithes, le code jaune et toutes ces choses, mais il y a aussi une quantité énorme de choses sur les humains, sur la gestion des attentes, sur l’entropie, sur la philosophie des systèmes, sur le risque, sur les externalités, sur les mauvais calculs, sur l’agence et sur la reconnaissance du fait que c’est un travail continu. C’est beaucoup plus proche de l’agriculture, où il faut s’occuper des cultures et reconnaître les cycles, que de l’industrie manufacturière, où il faut expédier le produit de la chaîne de production en espérant que le client n’appelle jamais. Et si quelque chose peut ressortir de tout cela,

[00:52:00] c’est que culturellement, je pense que les dirigeants doivent reconnaître que les équipes d’ingénieurs sont des agriculteurs qui s’occupent des cultures et non des usines qui produisent des choses qu’ils espèrent ne jamais revoir. Donc, merci beaucoup, tout d’abord, d’être ici, merci à IBM pour rendre cela possible. Et merci d’avoir écrit ce livre parce que c’est un livre vraiment merveilleux. Et je sais que notre ami, Sean Boots, à qui j’ai demandé de nous rejoindre ce matin, mais égoïstement, j’avais d’autres questions, il est dans le Yukon. Il est bien trop tôt pour lui, mais il dit, mais il y a tellement de gens comme Sean qui travaillent au front de taille depuis une décennie maintenant, des gens qui rencontrent AF et les President Innovation Fellows et le CVS et le GDS. Ils disent tous que ce livre reprend des choses qu’ils ont essayé de dire peut-être avec moins d’éloquence ou peut-être de manière ignorée parce qu’il n’était pas politiquement approprié de les dire et vous avez réussi à capturer une énorme quantité de ces choses dans ce qui est une lecture assez courte et divertissante. Merci beaucoup d’avoir rassemblé tout cela et c’est un plaisir d’apprendre à vous connaître un peu et d’aborder certains des sujets que vous avez soulevés dans le livre.

[00:53:02] Marianne Bellotti : [00:53:02] Eh bien, j’ai vraiment apprécié de parler aujourd’hui. Merci beaucoup de m’avoir invitée. [00:53:07] Alistair Croll : [00:53:07] Content de vous avoir vu.