Anton Onufriienko, Directeur Général de Devart – Série d’entretiens

Anton Onufriienko, Directeur Général de Devart, est un dirigeant technologique et opérationnel doté d’une expérience approfondie dans le développement de logiciels, la croissance des revenus et la direction d’équipes multifonctionnelles dans les domaines du SaaS, des logiciels d’entreprise et des services financiers. Au cours de sa carrière, il est passé de la construction d’organisations de ventes et du lancement de startups à la supervision de l’ensemble des opérations de produits et de services pour les principales unités d’affaires, y compris la plus grande division de Devart avec plus de 130 employés. Avant de devenir Directeur Général, il a occupé le poste de Directeur des Revenus et de Chef des Ventes de Devart, où il a dirigé la stratégie de lancement sur le marché, la transformation des prix et les initiatives de croissance internationale. Il est également PDG de TMetric, une plateforme de suivi du temps et de rentabilité axée sur l’aide aux entreprises à services pour acquérir une clarté opérationnelle.

Devart est une société de logiciels spécialisée dans le développement de bases de données, la connectivité de données, l’intégration et les outils de productivité pour les développeurs, les administrateurs de bases de données, les analystes et les équipes d’entreprise. Fondée en 1997, l’entreprise est surtout connue pour sa gamme d’outils de gestion de bases de données dbForge, qui prend en charge les principaux systèmes de bases de données, notamment SQL Server, MySQL, Oracle et PostgreSQL. Devart développe également des solutions de connectivité de données telles que les connecteurs ODBC, ADO.NET, Python et Delphi, ainsi que Skyvia, sa plateforme d’intégration de données sans code basée sur le cloud pour l’ETL, l’automatisation, la sauvegarde et l’orchestration des flux de travail. L’entreprise sert plus de 500 000 utilisateurs dans le monde, dont une grande partie des organisations du Fortune 100, et s’est de plus en plus concentrée sur l’intégration de capacités alimentées par l’IA dans ses produits, grâce à des outils tels que dbForge AI Assistant, qui aide les développeurs à générer, optimiser, dépanner et expliquer les requêtes SQL à l’aide de langage naturel.

Vous avez progressé de la construction et de la direction d’équipes de ventes à la gestion de l’ensemble des opérations de produits et de services et maintenant à la direction de la plus grande unité d’affaires de Devart. Comment ce parcours a-t-il façonné votre approche de l’intégration de l’IA dans la stratégie de produits et la prise de décision à grande échelle ?

Les ventes m’ont appris à mesurer le ROI de tout. En passant à un rôle de CRO, j’ai étendu cette discipline à l’ensemble des fonctions. La direction de l’unité d’affaires m’a forcé à l’appliquer à l’IA elle-même.

Je prends une vue pratique de l’IA. Ce n’est pas que je sois sceptique : trois de nos quatre paris de produits pour 2026 sont des produits natifs de l’IA. Mais je crois que l’hype se met en travers du chemin des résultats réels et durables.

Il y a une blague qui circule et qui résume bien où l’industrie va souvent mal. Les entreprises échangent des abonnements SaaS de 400 $ pour des outils maison qui coûtent 1 000 $ par mois en frais d’API et nécessitent des réparations constantes. Ce n’est pas un véritable changement, c’est juste un spectacle coûteux.

La leçon que j’ai retenue des ventes est simple : chaque initiative paie son chemin, ou elle meurt. Je gère notre déploiement de l’IA de la même manière que je gérais un territoire de ventes. Hypothèse de ROI explicite par flux de travail, déploiement en trois vagues et impact documenté avant de passer à l’échelle.

Notre métrique étoile est le Revenu par Employé, et notre objectif est de plus que doubler ce chiffre d’ici la fin de 2028. Vous ne fermez pas cet écart en embauchant. Vous le fermez en changeant ce à quoi ressemble le travail, et l’IA est le seul mécanisme réaliste à cette échelle.

Mon filtre pour chaque initiative d’IA, interne ou de produit, est le même : quelle est la valeur mesurée, qui paie pour cela et comment savons-nous que cela a fonctionné ? Tout ce qui échoue à ces trois questions n’a pas sa place en production. Le coût de l’erreur se accumule rapidement, et la plupart des entreprises vont le découvrir de manière coûteuse.

Devart a construit une solide réputation autour des outils de bases de données et de la productivité des développeurs. Comment intégrez-vous l’IA dans ces produits pour apporter une véritable valeur et non une automatisation de surface ?

Nos utilisateurs sont des spécialistes techniques chevronnés : administrateurs de bases de données, ingénieurs seniors, architectes de données. Ils détectent l’automatisation de surface en quelques secondes et ressentent une certaine rancœur lorsqu’on leur vend des jouets marketing déguisés en innovation. Il y a deux ans, lorsque l’hype de l’IA a culminé et que les concurrents se sont précipités pour ajouter des panneaux de chat à chaque élément d’interface utilisateur, la tentation de suivre était réelle. J’avais vu ce schéma auparavant, dans le domaine mobile, le cloud, le low-code, et j’ai refusé de le répéter.

La discipline était simple : la valeur du client d’abord. Construire des fonctionnalités d’IA que personne n’a demandées, qui n’apportent pas de valeur réelle, est la pire utilisation possible des ressources d’ingénierie finies. C’est particulièrement vrai lorsque votre public peut détecter la différence immédiatement.

Ce qui a changé en 2026, c’est que l’IA est passée de l’hype à une véritable révolution technique. L’écart entre ce que ces systèmes pouvaient faire en 2023 et ce qu’ils peuvent faire aujourd’hui n’est pas incrémental. C’est une catégorie de capacité complètement différente. Nous pouvons désormais résoudre des problèmes qui étaient réellement insolubles auparavant : l’accès sécurisé aux données d’entreprise pour les agents d’IA, l’intelligence contextuelle de la base de données à l’intérieur de l’IDE du développeur et les analyses commerciales autonomes qui n’exigent pas d’analyste dédié.

Ces derniers sont de nouvelles lignes de produits qui existent parce que l’IA a rendu le problème sous-jacent soluble. C’est la barre à laquelle nous nous mesurons : un produit d’IA réel est celui où la suppression de la couche d’IA brise le produit. L’industrie a passé deux ans à appeler les panneaux de chat « produits d’IA ». Ce sont des fonctionnalités, pas des produits.

Nous avons mis plus de temps parce que nous voulions faire les choses correctement. Les douze prochains mois montreront si cette discipline a payé.

L’IA est de plus en plus utilisée pour écrire, optimiser et déboguer du code. Comment voyez-vous cela changer le rôle des développeurs travaillant avec les bases de données au cours des prochaines années ?

La valeur de la connaissance de la syntaxe SQL diminue rapidement. Si l’IA peut générer une jointure multi-table complexe en quelques secondes et identifier les indexes manquants à partir des journaux en quelques minutes, la valeur d’un ingénieur ne provient plus de la saisie de code SQL. Cette partie du travail devient une denrée commune.

Mais voici la nuance critique que les évangélistes de l’automatisation totale omettent toujours. Une erreur d’IA sur le frontend est un bouton mal aligné que vous rechargez. Une erreur d’IA sur la base de données est un environnement de production effacé, une fuite de PII ou une fermeture transactionnelle de l’ensemble de l’entreprise.

Les bases de données contiennent un état. Elles ne pardonnent pas les hallucinations.

Cette asymétrie redéfinit complètement le rôle. Au cours des deux à trois prochaines années, les développeurs de bases de données et les administrateurs de bases de données évolueront de codeurs en architectes et en auditeurs. Leur travail principal se déplace vers trois choses :

• Concevoir des architectures fiables que l’IA ne peut pas raisonner par elle-même, car elle manque de contexte commercial.
• Établir des garde-fous et des politiques de sécurité strictes pour les agents d’IA qui touchent les systèmes de production.
• Examiner et auditer le code généré par les machines avant qu’il n’atteigne la base de données.

Le modèle mental auquel je reviens constamment : les ingénieurs géreront des armées d’assistants d’IA. Des outils comme dbForge devront évoluer d’IDE traditionnels en centres de commandement et d’audit. Le travail devient moins axé sur la saisie manuelle de code SQL et plus sur la vérification de ce que génère l’IA, la validation et l’application des limites que l’IA ne peut pas franchir en toute sécurité.

L’opportunité professionnelle est importante. Les développeurs qui passent à l’architecture et à la supervision multiplieront leur valeur sur le marché. Ils deviendront la couche indispensable entre la productivité de l’IA et la sécurité de la production. Le premium sur l’expertise en base de données ne disparaît pas ; il se déplace vers la conception, la gouvernance et le jugement, qui sont exactement les domaines où l’IA ne peut pas opérer seule.

Quelles sont les plus grandes limites des outils d’IA actuels dans la gestion de bases de données aujourd’hui, et où voyez-vous les percées les plus significatives ?

L’IA actuelle est encore coincée dans l’automatisation de surface. Générer une requête SQL de base ou du code de base n’est plus impressionnant. Le problème plus important est que la plupart des systèmes d’IA se comportent encore comme des dactylographes aveugles plutôt que comme des architectes de systèmes. Ils peuvent générer une syntaxe, mais ils ne comprennent vraiment pas l’environnement dans lequel ils opèrent. La véritable percée se produit lorsque l’IA commence à raisonner sur le contexte, les dépendances, l’état et la logique commerciale ensemble.

Actuellement, je vois trois limitations majeures qui freinent l’IA dans les environnements de bases de données.

Tout d’abord, il y a le problème du contexte. Les grands modèles de langage peuvent voir les schémas, les DDL, les noms de colonnes, mais ils ne comprennent vraiment pas les plans d’exécution, la fragmentation des indexes, les modèles de distribution des données ou la logique commerciale derrière les données. Sans cette compréhension plus approfondie, de nombreux conseils d’optimisation deviennent des devinettes statistiques déguisées en expertise.

Deuxièmement, il y a le problème des hallucinations, et les entreprises ont presque zéro tolérance pour cela au niveau de la base de données. Une jointure hallucinée peut ralentir les systèmes de production. Une mise à jour incorrecte peut effacer des enregistrements critiques. À ce niveau, même de petites erreurs d’exactitude peuvent devenir extrêmement coûteuses très rapidement.

Le troisième problème est la sécurité et la gouvernance. Aucune entreprise sérieuse ne va coller des schémas de production ou des PII dans un outil d’IA public sans garanties solides en matière d’isolement des données et de contrôle. Jusqu’à ce que les fournisseurs résolvent cela correctement, l’adoption de l’IA dans les industries réglementées restera limitée.

Les percées significatives se produiront lorsque l’IA passera de la génération de syntaxe à un fonctionnement plus proche de celui d’un architecte de systèmes ou d’un analyste en arrière-plan.

L’une de ces parties consiste à la couche sémantique : passer des noms de tables bruts à la signification commerciale réelle. Pas seulement « table_utilisateurs », mais la compréhension de concepts comme les cohortes de clients, le risque d’abandon, les tendances du LTV du trimestre 3.

Un autre déplacement est l’IA agissant plus comme un senior DBA en arrière-plan. En analysant continuellement les charges de travail, en identifiant les goulets d’étranglement, en suggérant des indexes, en repérant des requêtes à risque et en détectant les problèmes avant que les systèmes ne tombent en panne.

Ensuite, vous avez les opérations machine-à-machine, où des agents autonomes surveillent la charge de la base de données, testent des stratégies d’optimisation dans des environnements isolés et déployer des améliorations sous supervision humaine.

Ces développements seront ceux qui façonneront les cinq prochaines années d’outils de bases de données.

À partir de votre expérience en tant que dirigeant des revenus et de la stratégie de lancement sur le marché, comment l’IA réorganise-t-elle les modèles de tarification, les packaging de produits et l’acquisition de clients dans les sociétés de logiciels ?

Le livre de jeu traditionnel de lancement sur le marché est cassé. Nous le voyons dans nos propres chiffres et dans l’ensemble de la catégorie des outils de développement.

La mort de l’acquisition classique. Malgré des améliorations significatives de nos classements de recherche pour nos produits en 2026, nous sommes confrontés à la réalité des recherches sans clic. L’IA de recherche fournit des réponses directement sur la page des résultats et prive les sites Web de trafic. Des classements solides ne se traduisent plus par des prospects comme ils l’ont fait il y a même deux ans.

Il y a cinq ans, une solide stratégie de contenu suffisait pour stimuler la croissance. Aujourd’hui, c’est le minimum requis. Les LLM évaluent la force de la marque, les mentions positives et la densité de la communauté lorsqu’ils forment des réponses. Si votre marque n’est pas visible et de confiance, les systèmes d’IA ne la font pas apparaître de manière cohérente. Vous ne perdez pas seulement du trafic. Vous disparaissez complètement du parcours d’achat.

Ce déplacement frappe particulièrement fort les sociétés de logiciels traditionnelles de développement. Les canaux d’acquisition basés sur le référencement qui ont financé une génération de logiciels SaaS B2B perdent rapidement leur efficacité. Quiconque s’appuie encore sur eux comme principal levier de croissance doit être en train de construire des alternatives dès maintenant : distribution d’écosystème, communauté et partenariats.

Évolution de la tarification : des sièges au PLG 3.0. Nous entrons dans la prochaine phase du PLG. La tarification par siège commence à se briser lorsque un agent d’IA peut faire le travail de plusieurs employés. Dans cet environnement, facturer en fonction du nombre de sièges ne fait plus sens. Les sociétés qui ne repensent pas leurs produits autour de la valeur plutôt que du nombre de sièges vont perdre des revenus mensuels récurrents au cours des 24 prochains mois.

La prochaine étape est le PLG 3.0 : le moment où un agent d’IA autonome, et non un humain, évalue, teste et achète des logiciels d’entreprise. L’adoption massive de ce modèle est encore quelques années plus loin, mais concevoir des produits et des tarifs pour l’acheteur machine est une tâche pour 2026, et non pour 2028.

De nombreuses organisations ont du mal à passer de l’expérimentation de l’IA à un véritable impact sur la production. Quels sont les facteurs clés qui déterminent si les initiatives d’IA réussissent réellement ?

La plupart des fonctionnalités d’IA échouent avant même d’être construites. Elles échouent dans la salle où quelqu’un dit « nous avons besoin d’IA dans ce produit », non parce que les utilisateurs l’ont demandé, mais parce que le conseil d’administration veut une histoire d’IA ou que le marketing pense que cela attirera un nouveau public. C’est le péché originel de la plupart des initiatives d’IA, et cela façonne tout ce qui suit.

Je vois les mêmes erreurs se répéter dans les sociétés qui luttent pour passer de l’expérimentation de l’IA à un véritable impact sur la production.

La première erreur est de construire des fonctionnalités d’IA que personne n’a réellement demandées. Une fois qu’une fonctionnalité d’IA est imposée sans besoin réel, l’équipe travaille à rebours à partir de la technologie pour inventer un cas d’utilisation. Le résultat est prévisible : un panneau de chat vissé sur une interface utilisateur existante, une fonction d’autocomplétion qui gêne, un bouton « résumer » qui produit une sortie pire que ce que l’utilisateur pourrait écrire lui-même. Ces fonctionnalités sont lancées, font l’objet d’un communiqué de presse et sous-performent silencieusement toutes les prévisions d’adoption. Le préjudice plus profond est qu’elles consomment la capacité d’ingénierie qui aurait dû aller à des fonctionnalités que les utilisateurs ont réellement demandées.

La deuxième question est que les équipes sous-estiment massivement la différence entre les données de démonstration propres et les données de production réelles. Les démonstrations d’IA fonctionnent sur des exemples propres et soigneusement sélectionnés. La production fonctionne sur le véritable chaos des données client : les doublons, les champs manquants, dix différentes façons d’épeler le même nom de produit, quinze ans de cas de bordure hérités. Un modèle qui atteint une précision impressionnante lors de l’évaluation peut se dégrader sévèrement sur des données live, et la plupart des équipes ne découvrent cela qu’une fois que les utilisateurs se plaignent. Le coût de cette découverte en termes de confiance en production est rarement récupérable.

Un autre point d’échec courant est la recherche utilisateur. Les entretiens de produit standard ne fonctionnent pas pour les fonctionnalités d’IA. Les utilisateurs ne peuvent pas articuler ce qu’ils veulent de l’IA parce qu’ils ne savent pas ce qui est possible. Demander « utiliserez-vous l’IA pour faire X ? » obtient des réponses de oui polies qui n’ont aucune valeur prédictive pour l’adoption. La recherche de produit d’IA efficace nécessite de montrer des prototypes, d’observer une utilisation réelle et de mesurer si les utilisateurs reviennent après que la nouveauté se soit estompée. Peu d’équipes de produit ont reconstruit leur pratique de recherche pour cela. Elles utilisent encore les manuels de 2019 pour les problèmes de 2026.

Et enfin, de nombreuses sociétés mesurent l’activité d’IA au lieu de l’impact commercial. « Deux cents personnes ont utilisé la fonctionnalité d’IA cette semaine » est une métrique d’adoption, pas une métrique d’impact. L’impact réel est le temps de cycle réduit, la qualité améliorée, les revenus générés ou les coûts supprimés. Si vous ne pouvez pas tracer une ligne directe de la fonctionnalité d’IA à un chiffre du compte de résultat, vous n’avez pas d’impact sur la production. Vous avez une activité coûteuse.

Il y a un cinquième facteur qui devient de plus en plus critique et que la plupart des équipes de produit ignorent complètement.

La conformité et le chemin de construction sans IA. Une part significative des utilisateurs d’entreprise dans les domaines de la finance, des soins de santé, du gouvernement, de la défense et du droit opèrent dans des politiques qui interdisent ou restreignent les fonctionnalités d’IA dans les logiciels de fournisseurs. Si votre produit couple étroitement l’IA dans l’expérience principale sans moyen de la désactiver ou de la contourner, vous n’élargissez pas votre audience en ajoutant l’IA. Vous perdez un segment de votre audience existante.

C’est exactement le problème que nous résolvons avec la connectivité d’IA. Les équipes de conformité dans les industries réglementées ne s’opposent pas à l’IA elle-même. Elles s’opposent à ce que les données quittent leur périmètre. La solution n’est pas de supprimer l’IA ; c’est de donner à ces organisations une architecture d’IA qui correspond à leurs contraintes. C’est pourquoi la connectivité d’IA est livrée en local : la capacité d’IA reste, les données ne quittent jamais l’infrastructure du client et l’approvisionnement passe l’examen lors du premier cycle au lieu du troisième.

Les équipes qui résolvent ce problème conçoivent pour la conformité dès le premier jour. Les équipes qui le font mal découvrent le problème lors de l’examen de l’approvisionnement, lorsque l’affaire est déjà perdue.

Devart opère sur plusieurs écosystèmes de bases de données. Comment l’IA peut-elle aider à simplifier la complexité croissante de la gestion des données sur différentes plateformes ?

La douleur est réelle. Une entreprise Fortune 500 typique exécute huit à douze moteurs de base de données différents simultanément : une base de données Oracle héritée pour la finance, PostgreSQL pour les nouveaux services, SQL Server pour les opérations, Snowflake ou BigQuery pour l’analyse et de plus en plus un magasin de vecteurs pour les embeddings. Chacun a son propre dialecte, son propre outillage, son propre régime de gouvernance. Un développeur qui rejoint cet environnement peut passer trois mois à apprendre où se trouvent les données et qui est autorisé à les toucher.

L’IA ne résout pas cette complexité par elle-même. Elle amplifie tout contexte qu’on lui donne. Huit bases de données non connectées avec aucune métadonnée unifiée produisent huit ensembles de suggestions superficielles. C’est exactement le mode d’échec que nous voyons dans la plupart des déploiements d’IA sur les piles d’entreprise.

L’opportunité est une couche de contexte qui se situe entre les agents d’IA et les bases de données sous-jacentes. Une couche qui parle à toutes, normalise les métadonnées, applique des politiques de gouvernance unifiées et expose une interface MCP propre afin que tout agent d’IA, qu’il s’agisse de Claude, de GPT ou d’un modèle interne, fonctionne sur l’ensemble de l’actif avec des règles cohérentes.

C’est l’architecture que nous construisons avec la connectivité d’IA : un serveur MCP sur site avec une prise en charge multi-base de données, une couche sémantique qui capture les définitions commerciales une fois au lieu de forcer chaque agent d’IA à les réapprendre, un contrôle d’accès basé sur les rôles au niveau de l’opération SQL et des journaux d’audit complets.

La simplification n’est pas gratuite. Quelqu’un doit encore modéliser la couche sémantique et définir les politiques. Mais ce travail se fait une fois, et non à plusieurs reprises pour chaque agent d’IA que vous ajoutez.

Vous avez dirigé de grandes équipes multifonctionnelles. Comment l’IA change-t-elle la collaboration interne et la prise de décision entre les équipes de produit, d’ingénierie, de marketing et de ventes ?

La plupart des frictions entre équipes étaient en réalité des gens qui attendaient des informations des autres équipes. L’IA élimine cette friction plus rapidement que n’importe quel cadre de gestion.

Les changements sont pratiques et immédiats.

Dans le produit et l’ingénierie : un responsable produit pose une question de base de données en termes commerciaux clairs, « quelle est la variance du LTV à travers nos trois tarifs les plus élevés ? », et obtient une réponse actionnable sur le champ, au lieu de déposer un ticket Jira à l’analyse et d’attendre trois jours.

Dans le marketing et les données : l’analyse des cohortes se produit en ligne, et non à travers une file d’attente de demande. Le responsable marketing pose la question, obtient des chiffres et construit la campagne, le tout le même matin.

Dans les ventes et l’ingénierie : les réponses techniques pour les prospects n’exigent plus de planifier un appel avec un ingénieur senior. Le représentant des ventes obtient une réponse technique crédible en temps réel, et le cycle de vente se contracte.

Les décisions se déplacent dans la conversation plutôt que dans le suivi. Le modèle « laissez-moi vous revenir avec ce chiffre » meurt. Les réunions se contractent parce que l’IA gère les pré-lectures et les résumés qui consommaient la première moitié de chaque session.

Cela force un déplacement de gestion plus profond, et c’est celui que la plupart des équipes de direction sous-estiment.

Chaque société prétend être axée sur les résultats. Regardez sous le capot et la plupart fonctionnent encore sur des métriques de substitution : points d’histoire, lignes de code, tickets fermés, heures connectées. Nous avons utilisé l’activité comme une métrique de substitution pour la valeur parce que la valeur réelle était difficile à mesurer. L’IA brise cette métrique de substitution de manière permanente. Lorsqu’un agent peut écrire 10 000 lignes de code ou fermer 500 tickets de support en une minute, mesurer l’activité devient dangereusement trompeur.

Nous passons explicitement à une gestion véritablement axée sur les résultats, où la performance est mesurée strictement par le résultat et le jugement. Brutal dans la pratique, car la plupart des systèmes de performance ne sont pas conçus pour cela. Les personnes qui se cachaient derrière une activité élevée deviennent visibles immédiatement, et la direction doit être prête à agir sur cette visibilité.

La conséquence structurelle est des organigrammes plus plats. Les couches de coordination et de routage d’informations se contractent. Les organisations qui s’adaptent le plus rapidement fonctionneront avec structuralement moins de personnes à une efficacité plus élevée.

Avec l’émergence des outils de développement assistés par l’IA et des outils sans code, allons-nous vers un avenir où la gestion de bases de données deviendra accessible aux utilisateurs non techniques ?

Il y a une confusion dangereuse dans l’industrie en ce moment. Les gens traitent une base de données de projet latéral et une base de données d’entreprise héritée comme si elles étaient la même chose. Elles ne le sont pas.

Pour les petits projets verts, la démocratisation est déjà là. J’ai personnellement construit de petites applications de scratch sans compétences approfondies en gestion de bases de données. Si votre schéma entier rentre dans la fenêtre de contexte d’un LLM, l’IA fonctionne comme de la magie. Les développeurs de citoyens qui construisent des outils internes à une petite échelle seront une catégorie réelle et croissante.

La réalité de l’entreprise est complètement différente. Les bases de données héritées massives sont confrontées au même problème que les bases de code monolithiques : le mur du contexte. Vous ne pouvez pas faire rentrer quinze ans d’évolution de schéma non documentée, de dépendances interbases et de logique de déclencheur personnalisée dans une invite. Lorsque l’IA perd le contexte sur une grande base de données, les hallucinations ne se dégradent pas de manière fluide. Elles se multiplient de manière exponentielle.

Le risque qui est sous-discuté est la fausse confiance à grande échelle. Les interfaces de langage naturel sont particulièrement douées pour produire des réponses qui semblent plausibles mais sont subtilement fausses. Si une requête SQL a une erreur de syntaxe, vous obtenez un message d’erreur. Si une interface de langage naturel interprète mal « clients actifs » parce que vos données ont six définitions différentes de l’activité, vous obtenez un chiffre. Le chiffre semble correct. Il peut être faux de 30 %. L’utilisateur n’a aucun moyen de le savoir.

Donc, non, la gestion de bases de données d’entreprise ne deviendra pas un terrain de jeu pour les utilisateurs non techniques.

Le DBA citoyen est un mythe à grande échelle.

L’avenir appartient aux architectes de données experts qui utilisent des outils professionnels pour combler le fossé de contexte et construire une infrastructure qui permet à l’IA de fonctionner en toute sécurité au-dessus.

La solution structurelle est la couche sémantique : un vocabulaire contrôlé où les définitions commerciales sont fixées une fois et réutilisées à chaque interaction d’IA. Sans cela, l’accessibilité devient une responsabilité.

En regardant vers l’avenir, à quoi ressemblera un « kit de développement d’IA » natif, et comment les équipes devraient-elles commencer à se préparer à ce changement dès aujourd’hui ?

Un kit de développement d’IA natif n’est pas un chatbot vissé sur un IDE. La plupart de ce qui est commercialisé comme « natif d’IA » aujourd’hui est une interface de chat plus un modèle d’autocomplétion. C’est le minimum requis, pas la destination.

À mon avis, un kit de développement d’IA véritablement natif a besoin de trois choses.

Tout d’abord, l’IA a besoin d’un contexte profond. Elle doit comprendre votre base de code, votre infrastructure, vos décisions historiques et votre environnement de données de manière continue, et non juste à travers des invites collées dans une fenêtre de chat. La plupart des outils actuels échouent à ce test. Leur contexte se réinitialise à chaque session, et l’utilisateur paie le coût de le reconstruire constamment.

Deuxièmement, les outils eux-mêmes doivent communiquer correctement entre eux. Votre IDE doit parler à votre base de données, la base de données doit parler à votre pile d’observabilité, et le CI/CD doit parler à votre réviseur d’IA, etc. Le Protocole de Contexte de Modèle est en train de devenir la couche standard ici, avec 97 millions de téléchargements d’SDK par mois au premier trimestre 2026, en augmentation par rapport aux 100 000 de fin 2024. C’est la courbe d’adoption la plus abrupte que j’aie jamais vue dans les infrastructures de développement.

Troisièmement, l’IA de production nécessite de sérieuses barrières de sécurité. Aperçu de la zone d’impact avant les opérations destructives. Analyse des dépendances. Plans de rollback automatisés. Journaux d’audit par défaut. L’IA sans cela est fine pour les prototypes et dangereuse en production.

Comment se préparer, concrètement.

Vérifiez votre pile par rapport à ces trois composants. Chaque outil expose-t-il des API et un MCP ? Parle-t-il aux autres, ou est-il en silo ? A-t-il des contrôles de sécurité ? Les outils qui échouent à deux de ces trois sont des actifs à court terme.

Construisez l’infrastructure de contexte dès aujourd’hui. Documentez les schémas, les définitions commerciales et les décisions d’architecture dans des formats lisibles par machine. Un contexte riche n’est pas construit en un trimestre. Les équipes dont l’IA a cela en 2027 sont celles qui documentent aujourd’hui.

Faites tourner l’IA en production avant de penser que vous êtes prêts. Les équipes qui attendent une « stratégie d’IA » formelle avant de livrer seront à dix-huit mois des équipes qui apprennent déjà à partir de véritables échecs de production. Choisissez un cas d’utilisation à faible risque. Livrez-le. Construisez la musculature.

Les équipes qui prennent ces décisions aujourd’hui définiront la prochaine décennie de la façon dont les logiciels sont construits. La fenêtre est étroite, et elle est ouverte en ce moment.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Devart.