Nous avons passé deux jours au Dublin Tech Summit 2026. Les conversations étaient différentes de ce que nous attendions – pas par l'énergie, mais par l'honnêteté. Moins de « l'IA va tout changer », plus de « nous avons ajouté de l'IA – et maintenant ? »
Ce changement a été le point le plus intéressant de l'événement.
L'ambiance dans la salle
Nous étions venus avec un objectif précis : trouver des fondateurs et des responsables techniques qui posent les questions les plus difficiles. Non pas quel modèle d'IA utiliser, mais où l'IA crée une vraie valeur – et où elle ne fait que déplacer la complexité vers un endroit moins visible.
C'était exactement la conversation que l'événement avait déjà.
Le premier jour s'est déroulé surtout en conversations de couloir – improvisées, directes, souvent plus franches que tout ce qui se disait sur scène. Le deuxième jour a basculé vers les sessions, et celles-ci ont frappé plus fort.
La sécurité, la conformité, la gouvernance, le poids organisationnel que représente le maintien de l'IA en production. Ce qui nous a le plus frappés, ce n'est aucune intervention en particulier. C'est que des fondateurs et des CTO disaient tout haut des choses difficiles, sans les emballer dans un récit de réussite.
Les grands thèmes qui sont revenus au Dublin Tech Summit
De « comment ajouter de l'IA ? » à « comment bien l'utiliser ? »
Il y a un an, la plupart des conversations lors d'événements comme celui-ci tournaient autour de la même question : comment intégrer l'IA à notre produit ? Cette question est en grande partie réglée. Ce qui l'a remplacée est plus difficile.
Comment utiliser l'IA en toute sécurité et à grande échelle, sans créer d'exposition juridique dans six mois ?
Qui porte la décision quand le modèle se trompe ? Que coûte réellement la maintenance en production – non pas dans un environnement de démo, mais avec de vrais utilisateurs, de vraies données et de vrais cas limites ?
Pour les produits de santé, de fintech, d'assurance et d'entreprise, ce sont des exigences d'architecture porteuses. On ne peut pas rajouter la conformité à la fin d'un sprint.
La Ferrari et le vélo
Un cadrage est revenu sans cesse : l'écart entre ce qu'un client imagine quand il dit « je veux de l'IA » et le produit qui résoudrait réellement son problème.
Un fondateur qui demande de l'IA a peut-être d'abord besoin d'outils internes plus rapides, d'une meilleure infrastructure de données ou d'un parcours utilisateur central plus propre. L'IA fait souvent partie de la bonne réponse. Elle en est rarement la totalité, et presque jamais le bon point de départ.
Construire une démo n'a jamais été aussi facile. Construire quelque chose de sûr, conforme et prêt pour de vrais utilisateurs reste exactement aussi difficile qu'avant. L'IA ne comprime pas ce travail – elle le déplace. Vers les décisions d'architecture, les couches d'intégration, les choix d'infrastructure, la maintenance à long terme. Les équipes qui n'en tiennent pas compte le paient plus tard.
La sécurité ne peut pas rester une revue finale
La discussion sur la sécurité au DTS avait une autre tonalité que les années précédentes. Il ne s'agissait pas d'ajouter la sécurité comme une fonctionnalité. Il s'agissait du fait que le code généré par l'IA est fonctionnellement correct avant d'être sûr – et que cet écart n'apparaît ni dans les démos ni dans les campagnes de QA. Il apparaît en production, des mois plus tard, au pire moment.
Pour les équipes qui développent avec l'aide de l'IA, cela signifie que le processus de revue doit changer, pas seulement l'outillage. La revue structurelle doit être explicitement la mission de quelqu'un et intégrée au processus – pas une réflexion tardive en fin de sprint.
L'infrastructure : le problème du bon moment
L'une des sessions les plus concrètes abordait un constat que nous faisons sans cesse : les équipes sur-conçoivent trop tôt – en montant des clusters Kubernetes pour des produits de cinquante utilisateurs – ou n'investissent pas assez et découvrent que l'architecture ne tient pas quand la croissance arrive. Les deux erreurs coûtent cher. La seule différence, c'est le moment où l'on paie.
La question honnête : de quoi cette équipe a-t-elle réellement besoin pour fonctionner aujourd'hui, et de quoi aura-t-elle besoin dans douze mois ? Ce sont souvent des réponses très différentes.
Les conversations qui ont le plus compté
Les sessions étaient utiles. Les conversations de couloir l'étaient davantage – parce qu'elles étaient précises.
Un fondateur, trois mois après son tour d'amorçage, qui réalise que le périmètre de son MVP s'est considérablement élargi sous la pression des investisseurs et ne sait pas quoi retirer sans perdre l'hypothèse centrale. Un CTO dont l'équipe avait construit un agent IA interne pour un workflow et qui cherchait à étendre ce modèle sans recréer douze fois les mêmes problèmes d'intégration. Un responsable d'une entreprise healthtech réglementée qui demandait comment structurer la gouvernance de l'IA alors que les orientations réglementaires sont encore en cours de rédaction.
Pour ces questions, les conseils génériques ne servent à rien. Le contexte est tout : le stade, l'équipe, l'environnement de conformité, le workflow précis que l'on automatise.
Ce que nous en retenons
Le secteur pose des questions plus mûres. Moins sur les capacités, davantage sur la responsabilité, la maintenabilité et ce que les choses coûteront réellement dans douze mois.
Quelques sujets qui nous occupent encore :
L'écart de validation se creuse. Le codage agentique permet d'obtenir en un après-midi quelque chose qui ressemble à un produit et fonctionne comme tel. Il devient ainsi plus facile de prendre un prototype pour une preuve. Plus on construit vite, plus la discipline de validation compte.
L'écart entre la démo et la production est l'endroit où la plupart des produits cassent – non pas parce que le code est faux, mais parce que les décisions d'architecture, la gestion du périmètre et le passage de « ça marche » à « ça tient sous charge réelle » n'ont jamais été construits.
La sécurité se cumule. Les équipes qui la traitent comme une liste de contrôle le paient. Celles qui la conçoivent dès le premier jour ont un produit fondamentalement différent – et une discussion fondamentalement différente avec les acheteurs grands comptes.
Dans la salle, on ne demandait plus comment intégrer l'IA. On demandait ce qu'il en coûte de la maintenir – et ce qui se passe quand ça tourne mal.
Si cela rejoint ce sur quoi travaille votre équipe, nous sommes toujours ouverts à un échange – notamment sur l'architecture IA, la validation produit et l'écart entre la démo et la production.
