Lorsque nous avons commence a presenter notre bot IA a des clients entreprise, la premiere question etait toujours la meme : que se passe-t-il s'il modifie nos donnees ? C'est une inquietude raisonnable. Vous avez une instance Odoo de production qui gere l'ensemble de votre activite - ventes, stocks, comptabilite, ressources humaines. Donner acces a un outil d'IA a ce systeme semble risque. C'est pourquoi nous avons concu l'architecture pour rendre physiquement impossible au bot d'ecrire, modifier ou supprimer quoi que ce soit.
Le fondement est simple : le bot se connecte a Odoo via XML-RPC en utilisant un compte de service dedie qui dispose de permissions strictement en lecture seule. Ce n'est pas un interrupteur logiciel qu'on pourrait activer accidentellement. L'utilisateur Odoo affecte au bot dispose de droits d'acces personnalises au niveau du modele - acces en lecture aux modeles que le client approuve, zero permission d'ecriture/creation/suppression sur quoi que ce soit. Meme si notre code avait un bug qui tentait une operation d'ecriture, la propre couche de controle d'acces d'Odoo la rejetterait avec une erreur AccessError.
Nous sommes alles au-dela des simples permissions Odoo. La couche d'integration du bot n'a aucune methode d'ecriture implementee. Le client XML-RPC que nous avons construit n'expose que les operations search_read, fields_get et read. Il n'y a aucun appel execute_kw pour create, write ou unlink dans toute la base de code. C'est la defense en profondeur - meme si quelqu'un compromettait notre couche applicative, les outils pour modifier les donnees n'existent tout simplement pas dans le code deploye.
Le stockage des identifiants a ete une autre decision critique. Tous les details de connexion Odoo de chaque client - URL, nom de base de donnees, cle API - sont chiffres au repos avec AES-256-GCM. Les cles de chiffrement sont stockees separement des donnees chiffrees, suivant le modele de chiffrement par enveloppe. Nous utilisons un vecteur d'initialisation unique pour chaque operation de chiffrement, ce qui signifie que meme des identifiants identiques pour deux clients produisent des textes chiffres completement differents.
Les cles API elles-memes meritent attention. Nous utilisons le systeme de cles API integre d'Odoo plutot que de stocker des mots de passe. Les cles API peuvent etre revoquees instantanement par le client depuis son panneau d'administration Odoo sans nous impliquer du tout. Si un client veut couper l'acces du bot, il supprime la cle API et elle cesse immediatement de fonctionner. Pas de ticket, pas d'attente, pas de dependance envers nous.
Les donnees en transit sont protegees par TLS 1.3 pour toutes les connexions entre notre serveur bot et les instances Odoo des clients. Nous imposons la validation des certificats - pas de contournement des verifications SSL meme pour le developpement. Le serveur bot lui-meme fonctionne sur un VPS Hetzner isole avec une surface d'attaque minimale : pas de ports inutiles ouverts, authentification exclusivement par cle SSH, mises a jour de securite automatiques.
Une question que nous recevons des equipes informatiques est de savoir si les donnees des clients sont utilisees pour entrainer des modeles d'IA. La reponse est non, et l'architecture l'impose. Quand un utilisateur pose une question au bot, nous interrogeons l'Odoo du client pour les donnees pertinentes, les formatons dans un prompt, l'envoyons a l'API de Claude et renvoyons la reponse. Nous ne stockons pas les resultats de requetes au-dela de la session de conversation. Nous ne collectons pas de donnees pour l'entrainement. Les conditions d'utilisation de l'API de Claude stipulent explicitement que les entrees et sorties de l'API ne sont pas utilisees pour l'entrainement des modeles.
L'historique des conversations est stocke dans notre base de donnees avec le meme chiffrement AES-256-GCM utilise pour les identifiants. Les conversations sont liees a des utilisateurs Telegram individuels et automatiquement supprimees apres 30 jours. Un client peut demander la suppression immediate de toutes ses donnees de conversation, et nous pouvons l'executer en quelques minutes.
Les regles d'enregistrement d'Odoo ajoutent une autre couche de protection que la plupart des gens ignorent. Meme avec un acces en lecture, les regles d'enregistrement peuvent restreindre les enregistrements que l'utilisateur bot peut voir. Un client peut configurer son Odoo pour que le bot ne voie que les enregistrements de societes specifiques dans une configuration multi-societe, ou uniquement les produits approuves/publies, ou seulement certaines categories d'employes. Le bot herite automatiquement de toutes ces restrictions car il fonctionne comme un utilisateur Odoo standard.
Nous avons egalement implemente une limitation de debit a plusieurs niveaux. Le bot limite les requetes par utilisateur par minute pour prevenir les abus. Il limite le total des requetes par organisation cliente par heure pour eviter les couts incontroles. Et il dispose d'une limite de debit globale pour proteger notre infrastructure. Si une limite est atteinte, le bot repond avec un message courtois et l'utilisateur peut reessayer sous peu.
Pour les clients dans des industries reglementees, nous fournissons une reponse detaillee aux questionnaires de securite et pouvons organiser un audit de notre base de code par leur equipe de securite. Nous l'avons fait trois fois jusqu'a present, et chaque audit a confirme que l'architecture en lecture seule est authentique, pas juste du marketing. Un auditeur a specifiquement note que l'absence de methodes d'ecriture dans la base de code etait inhabituelle - la plupart des systemes implementent des methodes d'ecriture puis tentent de les bloquer au niveau des permissions, ce qui est inheremment moins securise.
Le resultat pratique de tout cela est que notre bot a traite plus de 10 000 requetes sur les instances Odoo des clients avec zero incident de donnees. Aucune ecriture accidentelle, aucune fuite de donnees, aucun acces non autorise. L'architecture en lecture seule n'est pas qu'une fonctionnalite de securite - c'est le principe de conception central du produit qui rend l'adoption en entreprise possible.