IoT sans matériel :
Le framework de pilotes IoT "Mock" d'Odoo 19

Le scanner à 3 000 $ sur le bureau de chaque développeur (ou pas)

Si vous avez déjà implémenté les modules Code-barres ou IoT d'Odoo pour un client en entrepôt, vous connaissez la douleur : on ne peut pas tester ce qu'on ne peut pas brancher. Scanners de codes-barres, balances électroniques, imprimantes d'étiquettes, tiroirs-caisses — ce ne sont pas les périphériques qu'on trouve sur le bureau d'un développeur en télétravail.

Le résultat ? Les développeurs écrivent du code d'intégration IoT à l'aveugle, le poussent en staging, et prient pour que ça marche quand l'équipe d'entrepôt branche le vrai matériel. Spoiler : ça ne marche généralement pas. Pas du premier coup. Parfois pas au cinquième.

Odoo 19 change complètement la donne. Le nouveau framework de pilotes IoT Mock permet de simuler des scanners, des balances, des imprimantes et d'autres périphériques directement sur votre machine de développement Linux ou macOS — aucun matériel requis. Cet article est un guide pas à pas pour configurer un environnement de test d'entrepôt virtualisé, écrit pour les ingénieurs QA et les partenaires d'implémentation qui se battent avec ce problème depuis des années.

Comment Odoo 19 a découplé les pilotes IoT du matériel physique

Dans Odoo 18 et versions antérieures, l'IoT Box était une dépendance obligatoire. Les modules de pilotes hw_* (ex : hw_escpos, hw_scale, hw_scanner) communiquaient directement avec les appareils USB/série via le Raspberry Pi de l'IoT Box. Sans la chaîne physique — appareil → USB → IoT Box → réseau → Odoo — impossible de tester quoi que ce soit.

Odoo 19 introduit une couche d'abstraction des pilotes qui s'intercale entre le module IoT et l'interface matérielle. Chaque pilote implémente désormais une classe de base IoTDriver standardisée avec deux backends concrets :

L'insight architectural clé : les pilotes mock émettent des payloads d'événements identiques aux pilotes réels. Vos workflows d'entrepôt, votre logique de traitement de codes-barres et vos gestionnaires de lecture de balance n'ont pas besoin de chemins de code de test séparés — ils reçoivent les mêmes structures de données, que l'entrée provienne d'un scanner physique ou d'une fixture JSON.

Configurer un environnement de test d'entrepôt virtualisé sur Linux/macOS

Voici la configuration que nous utilisons chez Octura Solutions pour chaque projet d'implémentation d'entrepôt. Elle permet à toute votre équipe — développeurs, QA et même chefs de projet — d'exécuter des flux complets de préparation/emballage/expédition sans toucher un seul équipement.

Étape 1 : Activer le mode IoT Mock

Démarrez votre instance Odoo 19 avec le flag mock. Cela indique au module IoT de charger les backends mock au lieu de scanner les appareils USB réels.

# Démarrer Odoo avec les pilotes IoT mock activés
./odoo-bin --addons-path=addons,enterprise \
           --iot-mock \
           -d ma_base_entrepot

# Ou le définir de manière permanente via paramètre système :
# Configuration → Technique → Paramètres → Paramètres système
# Clé :   iot.driver.mode
# Valeur : mock

Étape 2 : Configurer les fixtures d'appareils Mock

Les pilotes mock lisent des fichiers JSON de fixtures qui définissent le comportement simulé des appareils. Créez un répertoire mock_devices/ dans votre chemin d'addons personnalisé.

{
  "device_type": "scanner",
  "device_name": "Scanner Code-barres Mock",
  "connection": "usb",
  "responses": {
    "scan": [
      {"barcode": "5901234123457", "delay_ms": 200},
      {"barcode": "LOT-2026-03-A1", "delay_ms": 150},
      {"barcode": "WH/OUT/00042",  "delay_ms": 300}
    ],
    "mode": "sequential"
  }
}

{
  "device_type": "scale",
  "device_name": "Balance Entrepôt Mock",
  "connection": "serial",
  "responses": {
    "read_weight": {
      "value": 2.450,
      "unit": "kg",
      "stable": true
    },
    "tare": {"value": 0.0, "unit": "kg", "stable": true}
  }
}

Étape 3 : Enregistrer les appareils Mock dans Odoo

Une fois le mode mock actif, le module IoT découvre automatiquement vos fichiers de fixtures. Vérifiez dans IoT → Appareils — vous devriez voir votre scanner et balance mock listés avec un badge [MOCK].

# Dans un post_init_hook de module personnalisé ou un setUp de test :
from odoo.addons.iot.mock import MockDeviceRegistry

registry = MockDeviceRegistry(env)
registry.register_fixture('mock_devices/barcode_scanner.json')
registry.register_fixture('mock_devices/scale.json')

# Déclencher un événement de scan simulé :
scanner = registry.get_device('Scanner Code-barres Mock')
scanner.trigger('scan')  # Émet le premier code-barres de la séquence

Étape 4 : Écrire des scénarios de test automatisés

La vraie puissance réside dans les tests automatisés. Voici un cas de test qui valide un flux complet de préparation-emballage-expédition avec des appareils mock :

from odoo.tests.common import TransactionCase
from odoo.addons.iot.mock import MockDeviceRegistry


class TestWarehouseIoTFlow(TransactionCase):

    @classmethod
    def setUpClass(cls):
        super().setUpClass()
        cls.registry = MockDeviceRegistry(cls.env)
        cls.scanner = cls.registry.register_fixture(
            'mock_devices/barcode_scanner.json'
        )
        cls.scale = cls.registry.register_fixture(
            'mock_devices/scale.json'
        )

    def test_pick_pack_ship_with_mock_scanner(self):
        """Flux de préparation complet avec scanner simulé."""
        # Créer un bon de livraison
        picking = self.env['stock.picking'].create({
            'picking_type_id': self.env.ref(
                'stock.picking_type_out'
            ).id,
            'location_id': self.env.ref(
                'stock.stock_location_stock'
            ).id,
            'location_dest_id': self.env.ref(
                'stock.stock_location_customers'
            ).id,
        })

        # Simuler le scan du code-barres du picking
        self.scanner.trigger('scan', index=2)
        # → Émet "WH/OUT/00042"

        # Simuler le scan du code-barres produit
        self.scanner.trigger('scan', index=0)
        # → Émet "5901234123457"

        # Simuler la pesée du colis
        weight = self.scale.trigger('read_weight')
        self.assertEqual(weight['value'], 2.450)
        self.assertTrue(weight['stable'])

        # Valider le picking
        picking.button_validate()
        self.assertEqual(picking.state, 'done')

Étape 5 : Intégration CI/CD

Ajoutez les tests IoT à votre pipeline CI. Comme les pilotes mock ne nécessitent aucun matériel, ils s'exécutent sur n'importe quel runner CI Linux — GitHub Actions, GitLab CI, Jenkins — sans configuration spéciale.

name: Tests Intégration IoT
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: odoo
    steps:
      - uses: actions/checkout@v4
      - name: Exécuter les tests IoT mock
        run: |
          ./odoo-bin --iot-mock \
            --test-tags /module.test_warehouse_iot \
            --stop-after-init \
            -d test_db

Ce que cela signifie pour votre budget et votre calendrier

Pour le CTO ou le sponsor de projet qui lit ceci, voici la traduction de l'amélioration technique en impact business :