Cette question a une réponse courte, et c'est un piège. La liste des outils est facile à réciter, elle ne dit presque rien de la qualité de ce qui sera construit. Nous donnons quand même la nôtre, parce qu'un prestataire qui refuse de la donner a un problème.
Ce que nous utilisons
- Modèles de langage. Ceux d'Anthropic et d'OpenAI principalement, choisis tâche par tâche. Un classement à fort volume n'appelle pas le même modèle qu'une rédaction. Le choix est réversible : le code ne suppose jamais un fournisseur unique.
- Interfaces de programmation. Celles de vos outils métier, celles des régies publicitaires, celles des messageries et des systèmes de paiement. C'est là que se passe le vrai travail d'intégration.
- Base de données. Une base relationnelle, avec des règles d'accès par ligne, qui reste la source de vérité. Les modèles lisent et écrivent à travers elle, jamais à côté.
- Exécution. Des fonctions déployées en périphérie de réseau, des tâches planifiées et des files d'attente pour tout ce qui est long, coûteux ou susceptible d'échouer.
- Bases de connaissances. Vos documents découpés, indexés et cités, pour que le modèle réponde à partir de votre matière et non de sa mémoire.
- Droits et authentification. Une identité par utilisateur, des rôles, et des habilitations vérifiées côté serveur. Jamais côté navigateur seulement.
- Journalisation et supervision. Chaque action automatisée laisse une trace lisible, avec son coût, son résultat et son auteur. Des alertes partent sur les cas anormaux.
Pourquoi la liste n'est pas la réponse
Deux prestataires peuvent citer exactement les mêmes technologies et livrer deux choses radicalement différentes. Ce qui les sépare tient en cinq questions, qu'il faut poser juste après :
- Que se passe-t-il quand un appel échoue ? Nouvel essai, temporisation, file d'attente, abandon avec alerte : il faut une réponse précise, différente selon les cas.
- Qui a le droit de déclencher quoi ? Une automatisation qui tourne avec un compte tout-puissant est un incident en attente.
- Comment sait-on ce qui s'est passé ? Sans journal consultable, il n'y a pas de diagnostic possible, donc pas de correction possible.
- Combien ça coûte à l'usage ? Le coût des modèles se mesure à l'appel. Une architecture qui ne le mesure pas ne le maîtrise pas.
- Qu'est-ce qui reste déterministe ? Tout ce qui peut être une règle doit rester une règle. Le modèle n'intervient que là où le jugement est nécessaire.
Le modèle est le composant le plus visible d'une automatisation. C'est rarement celui qui décide de sa réussite.
Sur les plateformes sans code
Les plateformes de type n8n, Make ou Zapier sont d'excellents outils, et nous n'avons rien contre elles. Elles conviennent parfaitement à des enchaînements simples, peu volumineux, sans logique conditionnelle profonde. Elles deviennent coûteuses et fragiles quand le process se complexifie, quand le volume monte, ou quand il faut une reprise sur erreur fine.
Le vrai sujet n'est donc pas « code contre sans code », mais : à quel moment change-t-on de véhicule, et qui vous le dira honnêtement.
Une précision qui change tout : sur quel compte tourne l'IA
Quand nous pilotons vos automatisations, les appels aux modèles s'exécutent sur vos propres accès, votre compte, votre facture. Vous voyez la consommation, vous pouvez la plafonner, et vous pouvez couper. Ce point paraît administratif : il détermine en réalité qui contrôle l'outil, et il rejoint directement la question de la propriété.
Pour voir comment ces briques s'assemblent en pratique, la page Orchestrateur IA décrit le travail de pilotage, et cet article ouvre le capot.


