Aleksandr Surkov

Dans les articles précédents, nous avons parlé des principes d’un travail multi-agent mature : plan-and-execute, critic séparé, review selon une rubric, Reflexion, contrôle du contexte, journalisation des étapes et point d’arrêt clair. Aussi, nous avons vu comment ces approches peuvent être assemblées techniquement avec un framework agentique. Et nous avons expliqué pourquoi GitHub Copilot est particulièrement utile précisément dans l’IDE : à côté du code, des fichiers, du terminal et de l’état réel du projet. Après cela apparaît la question pratique suivante : si ce schéma de travail s’est déjà révélé utile plusieurs fois, comment éviter de le reconstruire à partir de zéro dans chaque nouveau dépôt ? J’ai essayé de trouver une réponse à cette question dans mon propre projet, ForgentFramework. Plongeons dedans et voyons ce que j’ai obtenu.

Dans l’article précédent, nous avons examiné Microsoft Agent Framework comme moyen d’assembler techniquement un système agentique : avec des agents séparés, des workflows, des tools, du state, du middleware, du hosting et de l’observability. Cette approche convient bien lorsque nous construisons notre propre solution ou un système de production fermé autour d’un processus clairement défini. Mais dans le travail DevOps quotidien, la tâche prend souvent une autre forme. Il ne s’agit pas de concevoir une plateforme agentique à partir de zéro, mais de comprendre rapidement un dépôt concret : ouvrir la configuration du pipeline, regarder le Dockerfile de l’application web, vérifier le Dockerfile du processus en arrière-plan, comprendre la structure du projet, comparer avec les instructions et, si nécessaire, exécuter des commandes dans le terminal. Construire son propre système agentique pour cela est possible, mais c’est long et pas toujours justifié. Dans ces scénarios, un outil déjà présent dans l’environnement de travail du développeur, capable de travailler à côté du code, des fichiers, du terminal et du contexte du projet, a beaucoup plus de valeur. C’est précisément là que GitHub Copilot dans Visual Studio Code devient intéressant.

Dans l’article précédent, j’ai analysé l’idée même du multi-agent : pourquoi il est utile de diviser une longue tâche en plusieurs rôles, et pourquoi un agent universel commence assez vite à montrer ses limites. Mais comment passer de la théorie à la pratique ? La question ne consiste pas seulement à inventer les rôles d’orchestrator, d’executor et de critic, ni à écrire leurs prompts. Il faut comprendre comment les agents vont concrètement interagir, où vivra l’état, comment connecter les outils, quand un seul agent suffit, et quand un workflow explicite devient nécessaire. L’une des solutions est Microsoft Agent Framework. Regardons-le de plus près.

Dans l’article précédent, j’ai parlé d’un agent isolé comme outil de travail pour les tâches DevOps. Nous avons vu en quoi un agent peut être utile tant que la tâche reste locale : collecter le contexte, analyser une configuration, trouver un point faible dans un pipeline ou préparer un brouillon de solution. Mais dès que la tâche devient plus longue, des problèmes peuvent apparaître. Il faut parfois relever séparément le contexte du pipeline, puis vérifier un Dockerfile ou un script de déploiement, puis, par exemple, comprendre si la correction proposée n’introduit pas un nouveau risque pour la release ou l’exploitation. En un seul passage, ce travail commence à se disperser, le focus de l’agent se perd et l’efficacité diminue. À ce moment-là, un seul agent commence à mélanger plusieurs types de travail en même temps. Il planifie, exécute, se vérifie lui-même et porte tout le contexte accumulé. Pour une tâche courte, cela reste encore acceptable. Pour une tâche longue, cela commence à se dégrader. C’est là que la solution devient la décomposition du travail en plusieurs rôles, chacun étant assuré par un agent IA distinct.

On parle aujourd’hui beaucoup des agents et de l’IA, un peu partout. En général, la discussion dérive rapidement vers l’un de deux extrêmes. Soit on affirme que ces outils remplaceront bientôt une part importante des spécialistes. Soit tout est ramené à un simple chat avec un modèle, avec la conclusion qu’il n’y a rien de fondamentalement nouveau. Mais en pratique, comme souvent, les choses sont différentes. Dans le DevOps, par exemple, les agents ne sont probablement pas encore capables de remplacer complètement une personne. En revanche, comme outil permettant de traiter plus vite les tâches routinières, ils se montrent extrêmement efficaces. Étudier le contexte d’un projet, parcourir des configurations, lire des logs, chercher des écarts entre environnements, et même travailler sur des scripts d’automatisation : c’est précisément dans ces tâches quotidiennes, souvent fastidieuses, que l’effet réel apparaît. L’IA ne remplace pas l’ingénieur. Mais un ingénieur qui comprend comment utiliser cet outil, et où l’utiliser, peut devenir plusieurs fois plus efficace.

Dans les applications web, les fonctionnalités liées aux fichiers sont très fréquentes : téléverser un fichier, le stocker quelque part, puis le restituer à l’utilisateur via un lien. Il peut s’agir de PDF, d’images, de fichiers CSV ou d’autres documents que l’application ne génère pas à la volée, mais qu’elle enregistre simplement avant de les afficher plus tard dans le navigateur. La solution la plus évidente consiste à placer ces fichiers sur le disque local de la machine où IIS est installé. Pour une petite solution, cela peut tout à fait fonctionner. Mais dès que le système devient un peu plus sérieux, des questions légitimes apparaissent : dans quelle mesure est-il vraiment fiable de stocker des fichiers utilisateurs sur le disque d’un hôte donné ? Si cet hôte est endommagé, recréé, migré ou simplement maintenu d’une manière différente de ce qui était prévu, la couche de stockage de fichiers devient vite un problème à part entière. En même temps, on n’a pas toujours envie de passer immédiatement à Blob Storage et de modifier entièrement le modèle de gestion des fichiers de l’application. Il est parfois plus pratique de conserver une approche familière pour Windows et IIS : des dossiers, des chemins UNC, un système de fichiers et une distribution classique des fichiers via le serveur web. Dans ce scénario, Azure Files monté en SMB constitue un bon compromis. Voyons donc cette approche comme un sujet d’ingénierie : comment connecter un Azure File Share à Windows Server, comment configurer IIS, pourquoi les droits posent presque toujours problème dans ce cas, et comment rendre l’ensemble réellement opérationnel.

La migration d’applications legacy vers le cloud est pleine de surprises. En général, on s’attend à rencontrer des problèmes dans le code, l’infrastructure ou le CI/CD, mais en réalité presque tout peut surgir. Cette fois, tout a buté sur Crystal Reports… Voyons comment nous avons réussi à migrer vers Azure App Service une application legacy en ASP.NET classique, qui utilise Crystal Reports pour générer des rapports.

Lorsqu’on parle d’envoyer des e-mails depuis un système d’entreprise, on imagine généralement qu’une application se connecte à un serveur SMTP, compose le message et l’envoie au nom de la logique métier. Mais lorsque cette logique métier vit directement dans SQL Server — ce qui est fréquent dans les systèmes legacy — il faut adopter une autre approche. Que faire si un e-mail doit être envoyé directement depuis une procédure stockée, un job SQL Agent ou un traitement planifié ? Dans SQL Server, on utilise généralement Database Mail et la procédure sp_send_dbmail. Voyons comment les configurer.

Cet article est consacré à un problème courant rencontré lors de l'automatisation d'infrastructure avec Azure DevOps, connu sous le nom de "second hop". Nous verrons pourquoi ce problème survient et comment le résoudre efficacement pour garantir une intégration fluide et une automatisation complète.

Travailler avec des machines virtuelles Linux dans Azure via Azure DevOps peut s’avérer complexe lorsqu’un accès SSH est requis sans utiliser de connexions de service. Les tâches standard d’Azure DevOps supposent la présence d’une connexion de service préconfigurée, ce qui rend l’utilisation de machines virtuelles dynamiques ou temporaires peu pratique et inefficace. Dans cet article, nous examinons des solutions à ce problème.

Lorsqu'on parle d'accéder à une machine virtuelle Azure sous Windows, on pense immédiatement au protocole RDP. Pourtant, dans un contexte DevOps, CI/CD ou d'automatisation, une approche plus souple est souvent nécessaire. PowerShell Remoting propose une alternative efficace et sécurisée au RDP, permettant une gestion rapide et automatisée des VM. Cet article vous montre comment configurer et utiliser PowerShell Remote pour gérer vos VM Windows dans Azure.

La sécurité des machines virtuelles dans le cloud ne peut pas être remise à plus tard. L'accès Just-In-Time (JIT) dans Azure réduit considérablement les risques d'accès non autorisé, en accordant l'accès uniquement lorsque c'est nécessaire et pour une durée limitée. Cet article explique comment configurer et utiliser le JIT dans Azure, comment ouvrir des ports sur demande, et surtout, comment l'intégrer à vos pipelines Azure DevOps pour garantir un maximum de sécurité et d’automatisation.

Initialement, j'avais l'intention d'écrire un article sur la pratique de l'utilisation des modèles YAML dans Azure DevOps pour encapsuler des étapes répétables dans les pipelines. Mais pendant le processus d'écriture, j'ai réalisé que de simples références à la documentation et des exemples de fichiers YAML ne seraient pas aussi intéressants sans les relier à un scénario. Ainsi, un court article purement technique s'est transformé en un texte volumineux dédié à plusieurs sujets, chacun étant intéressant en soi. En fin de compte, j'ai décidé de transformer ce texte en une mini-série d'articles. Voici la deuxième partie, consacrée à l'utilisation des modèles YAML dans Azure DevOps, en mettant particulièrement l'accent sur le passage de paramètres vers et depuis les modèles.

Initialement, j'avais l'intention d'écrire un article sur la pratique de l'utilisation des modèles YAML dans Azure DevOps pour encapsuler des étapes répétables dans les pipelines. Mais pendant le processus d'écriture, j'ai réalisé que de simples références à la documentation et des exemples de fichiers YAML ne seraient pas aussi intéressants sans les relier à un scénario. Ainsi, un court article purement technique s'est transformé en un texte volumineux dédié à plusieurs sujets, chacun étant intéressant en soi. En fin de compte, j'ai décidé de transformer ce texte en une mini-série d'articles. Bienvenue dans la première partie, dédiée au test automatisé, où je donnerai un bref aperçu de l'approche du test logiciel et décrirai un scénario que nous automatiserons à l'aide de pipelines YAML avec des modèles dans le prochain article.

Aujourd'hui, tout le monde a entendu les mots intelligence artificielle, réseaux de neurones, ChatGPT. Le sujet est si pertinent et important qu’il est tout simplement impossible de l’ignorer. Dans cet article, je vais discuter un peu de ce qu'est l'intelligence artificielle moderne et vous parler des services que vous pouvez utiliser dans Azure pour travailler avec les réseaux de neurones.

Il n'y a pas si longtemps, j'ai été confronté à une situation où l'un de nos agents de déploiement Azure DevOps a disparu du réseau. Tout allait bien avec la machine, Internet fonctionnait dessus, les paramètres du pare-feu et le groupe de sécurité réseau étaient également bons, mais Azure DevOps a cessé de voir l'agent. Que s’est-il passé et comment avons-nous résolu le problème ? Bienvenue dans l'article.

La dernière fois, nous avons compris comment fonctionne le cloud au niveau le plus bas. Et maintenant, je vous suggère de regarder à l'intérieur du nuage de l'autre côté. Je pense que tout le monde sait ce que sont les fonctions serverless (ceux qui ne le savent pas, allez quand même à l'article - vous le découvrirez là-bas :). Un exemple de telles technologies serverless est Azure Functions, l'un des outils les plus puissants qui vous permet de résoudre facilement et avec élégance de nombreux problèmes de calcul. Voyons donc comment fonctionnent les fonctions serverless et il n'y a vraiment pas de serveurs là-bas...

Dans la continuité de mes réflexions sur la structure interne des cloud, je voudrais aujourd'hui réfléchir à la façon dont ils fonctionnent généralement à l'intérieur du point de vue de l'ingénierie informatique. Essayons de réfléchir à de quelles couches et blocs Microsoft Azure peut être constitué.

Après avoir expliqué le fonctionnement des centres de données, j'aimerais ajouter quelques mots sur la garantie de la fiabilité et de la sécurité au sein des équipes travaillant chez les fournisseurs de cloud. J'ai une certaine expérience de travail pour un fournisseur de cloud et j'énumérerai ci-dessous quelques points que les employés de tout fournisseur de cloud doivent obligatoirement suivre.

Les technologies cloud sont devenues une partie importante de notre vie et dans la plupart des cas, les ingénieurs informatiques modernes ne peuvent pas imaginer leur travail sans interagir avec les services cloud. Mais les nuages ne fonctionnent pas d’eux-mêmes quelque part dans le ciel. Quelque part sur notre planète, il existe des centres de données dotés de nombreux serveurs qui hébergent tous les services SaaS, PaaS et IaaS que nous utilisons. Dans cet article, je parlerai un peu des centres de données - des « baleines » sur lesquelles se dressent les nuages.