Salah Awad — Des systèmes d’IA conçus pour tenir sous pression.

Salah Awad est architecte de solutions et d’entreprise et a exercé à trois reprises les fonctions de directeur des technologies. Installé en Île-de-France, il développe des logiciels professionnellement depuis 2007 dans les domaines des marchés financiers, des plateformes de contenus et de processus d’entreprise, des programmes nationaux d’administration numérique, des écosystèmes de start-up et de l’IA industrielle.

Il est aujourd’hui directeur de programme pour la transformation cloud d’un groupe mondial de l’aéronautique, où il dirige un programme de migration couvrant plus de 8 500 machines virtuelles. Il a auparavant été cofondateur, CTO et DSI d’une entreprise de formation industrielle propulsée par l’IA. Titulaire d’un master en informatique, il travaille en arabe, en anglais et en français.

Une décision défendable, accompagnée de ses preuves. Cela implique une évaluation de l’existant, des options d’architecture réellement concurrentes plutôt qu’une préférence déguisée en alternatives, et une grille de notation explicite — sécurité, disponibilité, interopérabilité de l’écosystème, utilisabilité, évolutivité et coût total de possession — appliquée à chacune.

J’ai mené précisément cette comparaison entre un bus de services d’entreprise centralisé, un modèle fédéré décentralisé où chaque département conserve son infrastructure derrière des contrats de communication standardisés, et une pile sur mesure associant gestion documentaire, conception low-code de dossiers et moteurs de processus métier. Le livrable est l’architecture cible, la feuille de route technologique et un raisonnement capable de résister aux objections de ceux qui doivent le financer.

L’IA classique est bornée : un modèle reçoit une tâche définie — transcrire cet appel, séparer ces locuteurs, traduire ce texte, retrouver ces documents, évaluer ce dossier — et renvoie un résultat mesurable par rapport à une vérité terrain. L’IA agentique permet au modèle de choisir des actions, d’appeler des outils et d’itérer vers un objectif.

Utilisez l’IA classique lorsque la tâche est bien définie et que la précision est mesurable. Elle est moins chère, plus rapide, auditable et bien plus facile à certifier. Utilisez l’IA agentique lorsque le chemin vers la réponse ne peut réellement pas être défini à l’avance — recherche en plusieurs étapes, orchestration entre systèmes ou traitement d’exceptions qui exigerait autrement une intervention humaine.

La plupart des programmes d’IA qui échouent ont choisi un agent alors qu’un pipeline aurait suffi, ou ont livré un agent sans condition de terminaison, sans contrat d’outil typé ni piste d’audit. Choisir la bonne voie concentre l’essentiel de la valeur architecturale.

Jamais en donnant à un agent un client HTTP générique. Publiez une surface d’outils sélectionnés — un serveur Model Context Protocol ou équivalent — où chaque outil constitue un contrat typé, nommé et propre à un domaine, plutôt qu’un générateur de requêtes ouvert.

Placez l’identité de l’agent derrière le même fournisseur d’identité que vos utilisateurs humains afin que chaque appel soit attribuable. Restreignez la portée des jetons d’accès à chaque outil plutôt qu’à l’ensemble des droits de l’appelant. Protégez tout outil générique de secours par un manifeste explicite. Bornez et tronquez les résultats. Consignez chaque invocation et ses arguments dans une piste d’audit immuable. La frontière de confiance se situe entre le modèle qui propose une action et le code déterministe qui l’autorise.

Elle consiste à concevoir en supposant que chaque contrôle finira par échouer, puis à superposer des contrôles indépendants pour qu’aucune défaillance unique ne soit fatale.

Pour les systèmes d’IA, ces couches sont : l’isolation réseau et de déploiement, jusqu’au fonctionnement totalement isolé lorsque les règles imposent de conserver les données sur site ; l’identité fédérée avec authentification multifacteur et contrôle d’accès par rôles ; l’isolation des données par tenant ; une surface d’outils contrainte pour chaque agent ; la vérification déterministe des sorties du modèle avant leur application ; le chiffrement des données au repos et des identifiants stockés ; la limitation de débit et les contrôles anti-abus ; les contrôles de la chaîne d’approvisionnement, comme les nomenclatures logicielles et l’analyse des dépendances dans la CI ; enfin, une journalisation d’audit immuable sur l’ensemble.

Pour les charges réglementées, de défense, souveraines ou industrielles soumises à de fortes contraintes de résidence, de confidentialité ou de connectivité, un déploiement sur site ou isolé peut être indispensable. Des modèles quantifiés à poids ouverts exécutés par un moteur d’inférence local peuvent assurer transcription, traduction, extraction, synthèse, classification et réponses fondées sur la recherche, tout en maintenant les données d’inférence dans le périmètre contrôlé lorsque les flux de sortie, de télémétrie et d’artefacts sont correctement configurés.

L’effort architectural porte sur l’abstraction des fournisseurs, afin que la même application utilise par configuration un moteur local ou une API hébergée ; un mode dégradé CPU pour les sites sans accélérateur ; un contrôle de concurrence pour ne pas saturer un GPU unique ; et le packaging de toute la pile pour les environnements sans accès à Internet.

Bien davantage que l’appel d’une API de transcription. Un pipeline de production doit détecter l’activité vocale pour segmenter l’audio, effectuer la diarisation pour établir qui parle et quand, utiliser un modèle de reconnaissance adapté au dialecte réellement employé plutôt qu’à la langue scolaire, corriger le vocabulaire propre au métier à l’aide d’un dictionnaire, appliquer une passe de correction et de suppression des hallucinations fondée sur un modèle, puis normaliser le texte avant toute analyse.

Ce n’est qu’ensuite que la couche la plus intéressante s’exécute : notation du sentiment, du risque, de l’empathie et de la qualité, suggestions d’orientation et historique conversationnel interrogeable. J’ai construit cette pile de bout en bout pour l’arabe levantin — en temps réel, avec identification des locuteurs, interface opérateur bilingue de droite à gauche et inférence locale afin que les enregistrements ne quittent jamais l’infrastructure de l’opérateur.

Lorsque le nombre de comptes dépasse le millier, la contrainte principale n’est plus une charge particulière mais la cohérence : savoir ce qui existe, qui en est responsable, ce qui a changé et ce qui est actuellement en panne.

Il faut pour cela un plan d’exploitation unique au-dessus des comptes plutôt que des outils par compte — un inventaire canonique inter-comptes des ressources de calcul, conteneurs, clusters et bases de données ; un modèle d’incident qui traverse les frontières de responsabilité ; et une gouvernance appliquée au niveau des landing zones plutôt que négociée compte par compte. Le réseau et la sécurité doivent être intégrés à ce même plan — réseaux virtuels segmentés, pare-feu de nouvelle génération et services DNS, DHCP et gestion d’adresses IP d’entreprise — faute de quoi l’inventaire est fictif. Ce n’est qu’une fois ce socle en place que l’automatisation apporte de la valeur.

L’alerte n’est pas l’exploitation. Une fois qu’un inventaire canonique et un plan unifié de gestion des incidents existent, des modèles de fondation gérés et des outils DevOps agentiques peuvent y être directement connectés — pour corréler les signaux dans tout le parc, attribuer l’incident au service responsable, expliquer la cause probable dans un langage exploitable par l’ingénieur d’astreinte et exécuter une remédiation bornée plutôt que d’appeler un humain pour dérouler manuellement un runbook.

La discipline d’ingénierie est la même que pour tout système agentique : surfaces d’action bornées, vérification déterministe avant toute modification et piste d’audit immuable de chaque action automatisée. Un agent capable de redémarrer un service ne doit pas, pour autant, pouvoir le supprimer.

Architecture cible et feuilles de route technologiques. Conception de systèmes d’IA agentique et classique, ainsi que revue d’architectures d’IA déjà en cours de réalisation. Architecture de plateformes multicouches sécurisées pour les environnements réglementés. Conception de programmes de transformation cloud et d’usines de migration, y compris gouvernance FinOps et ROI. Missions de CTO à temps partagé ou de transition couvrant l’audit technique préalable, la conception de l’organisation d’ingénierie et la gouvernance de la livraison.

Les missions sont menées en français, en anglais et en arabe, en Europe, au Moyen-Orient et en Amérique du Nord.