L'architecte de données à l'ère de l'IA

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 7 sur 7 du chapitre Penser comme un architecte de données, le premier chapitre du cours Data Architect. Chaque module se suffit à lui-même. Précédent : Connaître ses outils : les neuf questions · Suivant : le chapitre suivant : la modélisation des données

La question à laquelle répond ce module : qu’est-ce que l’IA change pour l’architecte de données, et qu’est-ce qu’elle ne change pas ?

L’IA change l’architecture, mais peut-être pas de la façon dont on le pense d’abord.

Souvenez-vous du point de départ de ce chapitre : j’ai passé la plus grande partie de ma carrière à être un bâtisseur. Pendant presque tout ce temps, construire du logiciel coûtait cher. Il fallait des personnes aux compétences spécialisées, et écrire du code, construire des intégrations, créer des applications et tester prenaient du temps ; même expérimenter une idée était un vrai investissement. L’IA change cette équation. Aujourd’hui, je peux décrire ce que je veux et faire générer par l’IA un modèle de données, de l’Apex, un flow, un composant Lightning, une intégration, des tests ou de la documentation remarquablement vite, et demain elle en fera encore plus.

Il est donc raisonnable de se demander : si l’IA peut faire une si grande partie de la construction, qu’advient-il de l’architecte ? Je pense que la réponse est que l’architecture devient plus importante, pas moins.

L’IA est un propulseur de fusée

J’ai utilisé cette analogie dans mes conférences :

L’IA est le propulseur. L’architecture est le système de guidage.

L’IA nous donne une accélération extraordinaire. Nous pouvons générer des applications, des modèles de données, des intégrations, des tests et de la documentation plus vite que jamais. Mais un propulseur ne décide pas où la fusée doit aller. Il fournit la poussée. Le système de guidage détermine la trajectoire et la corrige en route.

Sans un guidage solide, plus de poussée n’aide pas. Elle vous mène plus vite à la mauvaise destination. Le travail de l’architecte n’est pas de tout ralentir ; c’est de s’assurer que nous accélérons dans la bonne direction.

Image générée par IA.

Imaginez un outil d’IA qui construit une application dix fois plus vite qu’avant. C’est formidable si c’est la bonne application. Mais si le modèle de données est faux, si nous avons choisi le mauvais objet standard, mal compris où doivent vivre les données de référence, ou si la conception fonctionne au volume d’aujourd’hui et s’effondre avec un zéro de plus ? L’IA n’a pas supprimé l’erreur. Elle nous a aidés à construire l’erreur plus vite, et à construire beaucoup plus de choses dessus avant que quiconque s’en aperçoive.

Une mise en œuvre bon marché déplace la valeur

Quand la mise en œuvre coûte cher, l’attention va naturellement à la mise en œuvre : qui peut la construire, combien de temps cela prendra, si on peut même la faire fonctionner. À mesure que la mise en œuvre devient moins chère, une autre question compte davantage : que devrions-nous construire ? C’est une question d’architecture.

L’IA peut générer vingt objets ; l’architecte de données décide si nous devrions en avoir cinq. L’IA peut générer une intégration ; l’architecte décide si les données doivent même être copiées. L’IA peut créer un champ en quelques secondes ; l’architecte demande s’il a un sens clair, un propriétaire et une raison d’exister. L’IA construit ce que nous demandons, donc la qualité de ce que nous demandons compte plus que jamais.

Générer n’est pas juger

L’IA est très douée pour générer des options, et c’est extrêmement utile. Je lui demande trois façons de modéliser quelque chose, les compromis, de remettre en cause une architecture, de me dire ce qui se passe à 100 millions d’enregistrements ou où une conception pourrait échouer, ou de me proposer une alternative où Salesforce n’est pas le système d’enregistrement. Je veux que les architectes fassent cela.

Mais générer des options et les juger sont deux choses différentes. L’IA peut me dire ce qu’offrent l’option A et l’option B. Quelqu’un doit encore comprendre le métier assez bien pour savoir quels avantages comptent, quelles contraintes sont réelles, quel risque est acceptable, et quand une réponse est techniquement plausible mais fausse pour cette organisation. C’est du jugement, et c’est de l’architecture.

Voici comment cela se manifeste dans mon propre travail. Au cours de la dernière année, j’ai cessé d’écrire moi-même la plupart du code. Je donne les détails à l’IA et lui demande de générer les écrans et le code back-end, et elle le fait remarquablement bien.

Mais elle ne prend pas de recul pour porter un regard analytique plus profond. S’il y a un défaut dans le modèle de données ou la conception, elle ne le remet pas en question. Elle traite ce qui existe déjà comme une hypothèse et construit dessus, vite et avec compétence. Elle s’arrête rarement pour dire : « Avant d’ajouter ceci, le modèle que vous avez déjà mériterait peut-être d’être changé. » Regarder ce qui existe et se demander si c’est juste, et pas seulement si on peut construire la chose suivante dessus, reste le travail de l’architecte. Si vous voulez que l’IA remette en question une hypothèse, il faut le lui demander.

Le test de réversibilité s’applique toujours

Revenez à la question du module 3 : à quel point sera-t-il difficile de revenir sur cette décision ? L’IA change le coût de générer et de modifier du logiciel. Elle ne change pas le coût de modifier la réalité. Une fois 100 millions d’enregistrements chargés, ils existent. Une fois que douze systèmes dépendent d’un identifiant, ces dépendances existent. Une fois que des clients utilisent un processus, ou que des analyses dépendent du sens d’un champ, le changer a des conséquences. Et une fois que des données ont été partagées là où elles n’auraient pas dû l’être, aucune quantité de nouveau code ne les fait revenir.

L’irréversible reste irréversible.

Les agents sont un nouveau type de consommateur de données

Nous concevions autrefois les données pour deux types de consommateurs : les humains et les logiciels. Une personne lit un enregistrement ; un rapport, une intégration ou une application lit les données. Il y en a maintenant un troisième : les agents. Un agent peut récupérer des données, les interpréter, les combiner avec d’autres informations, décider et agir, parfois sans aucun humain entre les deux.

Cela fait monter les enjeux. Ce que signifie un champ, à qui il appartient, à quel point il est récent et fiable, s’il est sensible, si un agent peut et doit le voir, ce qui se passe quand deux sources ne sont pas d’accord : c’était autrefois de la documentation. C’est maintenant la façon dont un système intelligent comprend le métier.

Et les mauvaises données ne deviennent pas plus intelligentes parce que l’IA les lit. « Garbage in, garbage out » reste vrai. Les clients en double, la propriété floue, les identifiants incohérents et les systèmes de référence contradictoires ne disparaissent pas quand on connecte un agent ; les conséquences deviennent seulement plus visibles. Une personne regarde un champ et sait que personne ne l’a mis à jour depuis trois ans. L’agent n’a pas cette connaissance de l’organisation, et il peut agir avec assurance sur des données dont tout le monde savait tacitement qu’il ne fallait pas s’y fier. L’architecture de données devient une partie de l’architecture de l’IA.

Attention à la prolifération du schéma

L’IA rend aussi incroyablement facile de créer des choses. Besoin d’un autre objet, de six champs de plus, d’une autre automatisation ? Générez-les. Chaque décision semble bon marché, mais souvenez-vous de la gravité architecturale du module 3 : ces objets et ces champs accumulent des dépendances (automatisation, intégrations, rapports, agents), et bientôt vous avez un modèle de données que personne n’a conçu. Il a simplement poussé.

L’architecte doit être prêt à demander : « En avons-nous vraiment besoin ? » Parfois, la décision la plus précieuse est de ne pas créer quelque chose. Une bonne architecture tient autant à ce qu’on laisse de côté qu’à ce qu’on met dedans.

La revue humaine n’est pas une cérémonie

Quand je dis qu’un architecte humain doit revoir un modèle de données généré par l’IA, je ne veux pas dire « l’IA l’a créé, et Steve a regardé le schéma cinq minutes et l’a approuvé ». Ce n’est pas un contrôle. L’architecte doit comprendre le modèle : pourquoi ces objets, pourquoi ces relations, quelles alternatives ont été envisagées, où sont les clés et les données de référence, ce qui se passe quand le volume grandit, quelles sont les implications d’accès, et quels compromis ont été faits. Si je ne peux pas répondre, je ne suis pas propriétaire de l’architecture ; je l’ai approuvée les yeux fermés. L’IA peut contribuer à une architecture, la remettre en cause et la documenter, mais l’architecte humain doit pouvoir la défendre.

C’est la même chose pour les faits. J’utilise constamment l’IA pour apprendre et chercher, et ma règle est faire confiance, mais vérifier. Posez la question, demandez l’explication, les alternatives et une remise en cause de sa propre réponse. Puis, pour tout ce qui compte pour votre architecture, suivez le lien, lisez la documentation, vérifiez la limite, confirmez les licences et testez le comportement. L’IA peut être très convaincante quand elle se trompe, et distinguer les faits des hypothèses est maintenant une part encore plus importante du travail.

L’IA ne raccourcit pas le chemin

Il y a une phrase que j’utilise quand je parle de devenir architecte :

L’IA ne raccourcit pas le chemin. Elle peut faire compter davantage chaque pas.

Vous devez toujours comprendre les données, la sécurité, l’intégration, la plateforme et le métier, et il vous faut toujours l’expérience de prendre des décisions et de vivre avec leurs conséquences. L’IA peut accélérer votre apprentissage, vous montrer des scénarios que vous n’avez pas rencontrés, vous expliquer des choses, vous challenger, vous aider à construire et vous offrir un deuxième regard. Servez-vous de tout cela. Ne confondez simplement pas une IA qui connaît la réponse avec vous qui la comprenez.

L’architecte dirige

Nous avons commencé ce chapitre avec la personne qui tient le plan. L’IA donne à cette personne de nouveaux outils extraordinaires : un assistant capable de dessiner des parties du plan, de se renseigner sur les matériaux, de proposer des alternatives, de calculer les charges, d’écrire la documentation et même de repérer les problèmes que vous avez manqués. Servez-vous-en. Mais quelqu’un doit encore comprendre le bâtiment dans son ensemble, se demander si c’est le bon bâtiment, savoir ce qui se passe quand les exigences changent et quelles décisions seront coûteuses à défaire, et répondre du résultat.

C’est pourquoi le dernier niveau de ce cours s’appelle Direct (diriger). Vous n’écrirez peut-être pas chaque ligne de code, ne créerez pas chaque flow et ne construirez pas chaque objet. Quelqu’un doit encore diriger la solution, et c’est l’architecte. L’IA ne fait pas disparaître l’architecture ; elle change l’endroit où les architectes créent de la valeur. C’est une époque extraordinaire pour le devenir.

Ce que l’architecte décide ici

• Ce qu’il faut construire tout court, maintenant que construire coûte peu : quels objets, champs et intégrations méritent leur place.
• Quelles options générées par l’IA conviennent à ce métier, et lesquelles sont plausibles mais fausses.
• Quelles décisions coûteuses à défaire l’IA est en train de dépasser à toute allure.
• Ce que les agents peuvent lire et sur quoi ils peuvent agir, et si les données sont assez bonnes et assez bien décrites pour qu’ils le fassent.
• Quels faits venant de l’IA doivent être vérifiés avant de façonner la conception.

C’est cela, penser comme un architecte à l’ère de l’IA.