FAQ: Technologies de l'information (IT)

The Lokad app is a webapp provided as SaaS (Software as a Service). Le but de Lokad est de fournir des analyses prédictives afin d’optimiser la supply chain (meilleurs stocks, meilleurs prix, etc.). L’app Lokad est conçue comme une couche analytique qui opère en parallèle des systèmes transactionnels (ERP, WMS, CRM, etc.). Elle est proposée moyennant un abonnement mensuel forfaitaire qui regroupe généralement l’app elle-même et des services professionnels. Ces services professionnels, fournis par les ingénieurs de Lokad (Supply Chain Scientists), limitent presque entièrement le besoin de support technique du département informatique pour ce périmètre. La seule contribution clé attendue du département informatique est la mise en place d’un pipeline de données envoyant des fichiers plats (par SFTP ou FTPS) vers Lokad, et potentiellement la réintégration des résultats générés.

Public visé : Le département informatique
Last modified: November 30th, 2023 -> Dernière modification : 30 novembre 2023

Aperçu technique

L’app Lokad est multi-locataire. Chaque locataire (c.-à-d. compte client) dispose de son propre système de fichiers dédié et de son propre dépôt de code. Le système de fichiers est accessible via FTPS, SFTP et une interface web. Ce système est conçu pour des fichiers plats volumineux (jusqu’à 100 GB par fichier) et offre un versionnage des données (comme Git). Le dépôt de code sert à héberger des scripts Envision. Envision est un DSL propriétaire (langage de programmation spécifique à un domaine) développé par Lokad. Ce DSL est fortement spécialisé pour des cas d’optimisation prédictive. Les scripts Envision sont utilisés pour effectuer les analyses numériques de base (y compris des algorithmes de deep learning, des solveurs, …) et pour générer des tableaux de bord riches en données.

L’app est redéployée entièrement chaque mardi entre 10:00 et 14:00 (heure de Paris). Le temps d’indisponibilité est généralement inférieur à 5 min. Lokad assume l’intégralité des préoccupations liées au versionnage.

Le département informatique n’est pas censé acquérir une compétence spécifique sur la stack de Lokad. Cependant, si vous êtes curieux, il existe une documentation technique complète.

Aperçu de la contribution du département informatique

Nous attendons du département informatique qu’il mette en place un pipeline de données qui envoie une courte série d’extractions pertinentes de fichiers plats vers Lokad par SFTP ou FTPS. Les extractions sont réalisées sur les systèmes transactionnels (ex : ERP). Nous privilégions fortement les extractions de tables brutes (sans filtre, sans jointure, sans transformation), ce qui nécessite un effort minimal. Du point de vue de l’ETL, nous ne requérons que la partie ‘E’ (extraction) sous sa forme la plus simple (simple copie). En termes de format, Lokad est compatible avec tout fichier plat raisonnablement tabulaire.

Le pipeline de données est censé fonctionner au moins quotidiennement et être entièrement automatisé. La charge de travail pour le département informatique dépend de la portée de l’extraction des données (quels systèmes ? quelles tables ?). Cependant, en règle générale, la mise en place du pipeline nécessite généralement entre 15 et 45 jours-homme, même pour les grandes entreprises. Une fois le pipeline en place, Lokad requiert typiquement une surveillance minimale du département informatique, habituellement assurée avec 1 ou 2 jours-homme par mois.

Aperçu de la sécurité

L’app est hébergée dans des centres de données Microsoft Azure situés dans l’UE. Nous ne traitons aucune donnée personnelle, car celles-ci ne sont pas nécessaires à notre fonctionnement. Lors de la définition de la portée de l’extraction, nous excluons toute colonne ou champ susceptible de contenir des données personnelles.

Pour l’authentification, nous privilégions SAML. Nous recommandons vivement que les utilisateurs accèdent à Lokad via une identité fédérée telle que Azure Active Directory, Office 365 ou Google Workspace. Cela élimine tous les problèmes liés aux mots de passe.

Sur demande, des audits de sécurité et des tests de pénétration peuvent être réalisés par nos clients. Les détails dépendent des accords négociés.

Pour plus de détails, consultez Sécurité chez Lokad.

Aperçu de la chronologie

La Supply Chain Quantitative est plus un voyage qu’une finalité en soi. Pourtant, en même temps, le leadership supply chain qui engage son entreprise dans la réalisation d’une initiative de la Supply Chain Quantitative requiert de la visibilité quant au calendrier du projet. Bien que des retours positifs puissent être obtenus en quelques mois, il faut fréquemment jusqu’à deux ans pour libérer le plein potentiel de la Supply Chain Quantitative. Dans l’article suivant, nous proposons un aperçu d’un calendrier typique associé à une initiative de la Supply Chain Quantitative pour une entreprise de taille moyenne. Pour les grandes entreprises, il faut s’attendre à ce que les délais soient deux fois plus longs.

Lancement du projet : Des représentants des deux parties se présentent mutuellement et organisent des réunions hebdomadaires. Ces réunions hebdomadaires se poursuivront jusqu’à l’atteinte de la phase de Production. Le Supply Chain Scientist présente les différentes phases de mise en œuvre et les divers livrables que le client peut attendre. Le reste de l’appel est consacré à l’examen de divers détails supply chain et des caractéristiques informatiques de l’intégration. Après l’appel, un compte rendu documentant les aspects organisationnels du projet est rédigé et envoyé au client.

Spécifications des données : Peu après la réunion de lancement, le Supply Chain Scientist rédige les spécifications des données requises pour la mise en œuvre du projet. Ces spécifications sont examinées et validées conjointement avec le client. En particulier, ce document doit définir les données à extraire des systèmes informatiques du client. En règle générale, l’extraction doit rester aussi proche que possible des données originales telles qu’elles existent dans les systèmes informatiques du client.

Premier chargement de données : Après validation des spécifications, le premier ensemble de données est transféré sur les serveurs de Lokad par le client. Généralement, à ce stade, le chargement n’est pas encore réalisé par un processus automatisé, plusieurs tentatives étant habituellement nécessaires pour établir un consensus sur les détails fins des spécifications.

Validation des données : Le Supply Chain Scientist procède à une analyse approfondie du contenu du jeu de données du client. En particulier, des contrôles de cohérence sont mis en place pour surveiller la qualité des données selon plusieurs indicateurs. L’objectif est de s’assurer que 1) le jeu de données est correctement actualisé par le processus de chargement, 2) il reflète fidèlement la réalité de l’entreprise et 3) il est suffisamment cohérent et complet pour les besoins d’optimisation de la supply chain.

Du point de vue des livrables, durant cette phase, le Supply Chain Scientist fournit au client divers tableaux de bord qui évaluent la santé des données. Ces tableaux de bord peuvent être utilisés par le client même pour des finalités allant au-delà de l’initiative de la Supply Chain Quantitative — par exemple dans le cadre de leur processus interne d’assurance qualité des données.

Audit mi-parcours : 6 semaines après le lancement initial, une réunion est organisée pour évaluer l’état d’avancement du projet. L’objectif de cet « audit » est de traiter, le plus tôt possible, les problèmes susceptibles d’être rencontrés lors de la mise en œuvre, en particulier ceux qui pourraient retarder la phase de production. Chez Lokad, cet « audit » consiste en un échange entre le Supply Chain Scientist et le client, s’appuyant sur une liste de vérification communiquée au client en amont par le Supply Chain Scientist, juste après la réunion de lancement.

Automatisation du chargement : Une fois que les deux parties valident la qualité globale du jeu de données chargé jusqu’à présent, le client met en place un processus automatisé qui transfère son jeu de données vers Lokad de manière régulière — idéalement quotidiennement. Parallèlement, du côté de Lokad, la logique de contrôle de la santé des données — avec ses multiples vérifications — est programmée pour être actualisée après chaque chargement.

Mise en place de l’optimisation : À partir de ce moment, le Supply Chain Scientist dispose de tous les éléments nécessaires pour mettre en œuvre l’optimisation des décisions préalablement convenues avec le client. Il implémente donc des scripts pour générer différentes sorties quantitatives : suggestions d’achats opérationnels, suggestions d’expédition, etc. Les chiffres obtenus par ces scripts peuvent être visualisés sous forme de tableaux de bord. À ce stade, ces tableaux de bord ne représentent qu’une version préliminaire des tableaux finaux et doivent être révisés conjointement avec le client.

Retours et ajustements : Les demandes du client visant à modifier ou à « ajuster » les différentes sorties entraînent généralement une fine adaptation des scripts écrits par le Supply Chain Scientist. De nombreux paramètres et méthodes peuvent être adoptés pour aligner correctement les caractéristiques de la supply chain optimisée avec la logique d’optimisation. Lorsque la méthodologie revêt une importance stratégique pour le client, cela est discuté explicitement entre ce dernier et le Supply Chain Scientist.

Production : Après plusieurs cycles d’ajustement et de révision, le client atteint un stade où il fait confiance à la logique mise en œuvre par le Supply Chain Scientist. À ce moment-là, le client peut commencer à utiliser le service en production, c’est-à-dire qu’il peut exécuter directement les décisions supply chain telles qu’initialement calculées par le logiciel. Lorsque le client valide que la solution est prête pour la production, le Supply Chain Scientist fournit une documentation garantissant la maintenabilité de la solution.

Support et maintenance : La solution est opérationnelle et utilisée par le client tandis que le Supply Chain Scientist surveille l’exécution quotidienne sans accroc du pipeline de données. Des appels sont organisés régulièrement entre le client et le Supply Chain Scientist pour vérifier que l’optimisation offre le niveau de performance supply chain attendu. De plus, les supply chains ne sont pas statiques, ainsi, des changements commerciaux ou informatiques — petits ou grands — doivent être réévalués : un nouvel entrepôt, un déplacement du marché, un nouveau processus, etc. Le Supply Chain Scientist propose les modifications appropriées pour tenir compte de ces divers changements. Des points de suivi sont planifiés à une fréquence convenue, généralement mensuelle.

Questions fréquemment posées (FAQ)

1. Gestion des versions

1.1 Comment fonctionnent les releases pour Lokad?

Lokad gère toutes les releases en interne, ce qui permet d’assurer une transparence totale pour les clients. Toute release susceptible d’impacter un client est coordonnée avec celui-ci — via ses équipes techniques — bien à l’avance. En règle générale, Lokad adopte une approche prudente en matière de releases : si une release programmée n’offrait pas suffisamment de temps de préparation pour un client, celle-ci serait temporairement reportée.

Les releases de Lokad sont très granulaires, et la conception permet généralement au client de refuser un élément technique particulier d’une release globale. Ainsi, si nous devons reporter la mise en œuvre d’un élément — pour lequel notre client n’est pas encore prêt — la release globale peut néanmoins avoir lieu (et mettre en œuvre les autres éléments non impactants).

1.2 À quelle fréquence les releases?

Lokad publie une nouvelle version chaque mardi, généralement vers 11 AM (CET).

1.3 Fournissez-vous un planning des releases à venir?

Oui, voir Gestion des versions 1.2.

1.4 Un changement de version implique-t-il une réinstallation ou simplement un correctif?

Lokad redéploie, par des moyens automatisés (scripts), sa propre solution. Nous ne patchons pas les systèmes en production. Si nous avons un “security patch” à déployer, nous redéployons la solution par nos moyens automatisés habituels.

1.5 Combien de temps faut-il pour appliquer une release majeure?

Le processus automatisé prend environ 1 heure. Il y a un déploiement progressif (machine par machine), car nous avons l’intention de maintenir la plateforme de Lokad opérationnelle et accessible pendant la release. La conservation de l’opérationnalité lors d’un déploiement progressif est abordée dans Gestion des versions 1.7.

1.6 Qui est responsable de la bonne exécution de la release?

L’équipe de Lokad assume l’entière responsabilité de la bonne exécution de la release.

1.7 Avez-vous un temps d’arrêt durant la release?

En général non, mais gardez à l’esprit que la solution de Lokad est un système distribué dédié aux calculs à grande échelle. En conséquence, l’impact d’une release varie entre les systèmes front-end et back-end. Les sous-systèmes orientés client, tels que les tableaux de bord, sont conçus pour être disponibles sans interruption. Les systèmes back-end, quant à eux, chargés de l’exécution des traitements par lots, peuvent être mis en pause pendant quelques minutes (du moins pour certains traitements). Toutefois, ces traitements par lots peuvent être programmés, de sorte qu’une planification proactive devrait permettre leur achèvement en dehors de la fenêtre de release.

1.8 Quel est votre processus ou votre stratégie de test pour une release?

Lokad utilise des processus automatisés dédiés aux tests et à l’assurance de la justesse d’une release à venir. Ces processus incluent de vastes suites de tests automatisés (comptés par milliers) ; des tests unitaires, fonctionnels, de performance, etc. Nous avons également conçu des outils spécifiques qui nous permettent de reproduire des séquences complètes d’exécutions de travaux passés au sein de la plateforme de Lokad. Ces outils nous permettent de vérifier que les scripts Envision se comportent exactement de la même manière avant/après une release à venir. De plus, nous pouvons vérifier que les profils de performance des scripts existants restent conformes aux attentes de planification, telles que définies par nos clients.

1.9 Avez-vous plusieurs environnements?

Oui, cependant, les environnements alternatifs (au niveau de la plateforme, en dehors de celui de production) ne sont généralement pas destinés à nos clients. En plus de l’environnement de production et des environnements de développement transitoires, nous disposons d’un environnement “evergreen” qui correspond à la dernière version stable de notre dépôt de code. Cela valide un sous-ensemble spécifique de nos processus de test automatisés. Nos clients peuvent accéder à notre environnement “evergreen” afin de valider le comportement d’une release à venir spécifique. En pratique, cette situation est peu fréquente.

Si l’objectif est de pouvoir exécuter (côte à côte) plusieurs variantes de scripts Envision, alors un compte Lokad peut être partitionné en plusieurs “environments”. Si l’objectif est de pouvoir effectuer tout type de test, alors un deuxième compte Lokad peut être fourni pour des tests transitoires. Cette seconde approche permet d’isoler le compte client principal (utilisé en production) de ces tests.

1.10 Combien de versions différentes peuvent coexister ?

Lokad est un SaaS multi-tenant qui exécute la même version unique pour tous ses clients, cependant, Lokad a la capacité de faire fonctionner autant de versions distinctes que le client le souhaite.

1.11 Un client peut-il refuser une release ?

Comme Lokad est un SaaS multi-tenant qui exécute la même version unique pour tous les clients, il n’est pas possible de se désengager d’une release. Cependant, d’un point de vue commercial, cela importe peu puisque toute “modification” est mise en œuvre par l’exécution de scripts Envision au sein de la solution Lokad.

Pour les situations où une release peut être temporairement reportée, voir Release Management 1.1.

1.12 Avez-vous des release notes ? Les fournissez-vous à vos clients ?

Oui. Ces release notes sont partagées en interne (avec nos équipes de Supply Chain Scientist). Si cela est explicitement prévu dans un contrat, ces release notes peuvent être rendues accessibles à un client. En pratique, les release notes de la plateforme Lokad n’intéressent que les personnes qui travaillent avec le code Envision.

1.13 Quel est le processus pour qu’un client demande une évolution de la solution ?

La majorité de nos clients bénéficient d’une offre “software + expert”, dans laquelle une équipe de Supply Chain Scientist de Lokad est en charge de la mise en œuvre et de la maintenance de la solution supply chain d’un client. Ces situations sont connues sous le nom de “supply chain as a service”. Dans ce dispositif, le client interagit régulièrement avec un (ou plusieurs) Supply Chain Scientist. De plus, la plupart des clients bénéficient d’un comité de pilotage hebdomadaire ou mensuel pour discuter de l’état actuel de la solution et des évolutions souhaitées. Cette méthode est utilisée par Lokad pour recueillir toutes les demandes d’évolution et proposer une feuille de route pour la mise en œuvre des changements.

1.14 Est-il possible d’administrer le service web de l’application et de configurer ses paramètres ?

Oui, dans la mesure où la plateforme Lokad est de nature programmatique. La logique “analytique” de Lokad se présente sous forme de scripts Envision – Envision étant le DSL (Domain-Specific Language) conçu par Lokad dans le but de l’optimisation prédictive de supply chain.

Ainsi, en un sens, chaque configuration de paramètre est accessible en tirant parti de scripts Envision dans le compte.

2. Performance

2.1 Votre SLA (accord sur le taux de service) couvre-t-il une disponibilité de 99.xy% ?

Oui. Le SLA fait partie de notre contrat-type. Cependant, la notion de disponibilité dans le contexte d’un système informatique distribué – dédié à l’optimisation prédictive de supply chain – est complexe. Considérez les scénarios suivants : - Lokad reçoit les données client (une étape quotidienne) avec 2 heures de retard. Cela peut très bien perturber l’efficacité ordinaire de nos heuristiques d’allocation de ressources. Ceci, à son tour, peut prolonger le temps nécessaire à l’exécution des batch jobs de Lokad (par exemple, 75 minutes au lieu des 60 habituelles). Certains considéreront cela comme une indisponibilité de 15 minutes, mais cela échappe à notre contrôle.

• Lokad reçoit les mêmes données client à l’heure, mais les données présentent une baisse significative des niveaux de stocks. Cela déclencherait une interruption des batch jobs (côté Lokad) et alerterait un Supply Chain Scientist pour qu’il examine le problème. Le Supply Chain Scientist constate qu’une commande de réapprovisionnement automatisée est exceptionnellement élevée. Il décide qu’une évaluation directe auprès du client est nécessaire. Le lendemain, le client confirme que les données de stocks étaient corrompues et qu’elles auraient entraîné une importante radiation de stocks. Certains considéreront cela comme une indisponibilité de 24 heures, mais cela paraît pratiquement absurde dans ce contexte.

Le plus grand danger pour une solution d’optimisation de la supply chain n’est pas d’être un peu en retard ; c’est d’être totalement erronée. Une fois qu’une décision supply chain est prise, par exemple en déclenchant (à tort) un batch de production, l’annuler peut s’avérer extrêmement coûteux. Nous encourageons nos clients à ne pas s’attacher de manière arbitraire à des indicateurs isolés, car cette attitude peut inciter à fournir un travail global inférieur du simple fait qu’il semble satisfaire un KPI (tel qu’un uptime de x.y%).

2.2 Garantissez-vous un temps de réponse pour les demandes des utilisateurs en moins de X secondes ?

Oui, en dessous de 500ms, mais avec des réserves.

Nous avons conçu ce qui revient approximativement à des “dashboards en temps constant”. Dans les coulisses, l’affichage d’un dashboard nécessite une seule requête sur le réseau et, dans notre back end, nous collocons toutes les données du dashboard afin de limiter le nombre de requêtes réseau (généralement de l’ordre d’un seul chiffre). Ce design contribue grandement à “garantir” la faible latence de la requête utilisateur typique lors de l’affichage d’un dashboard. Ce choix de conception empêche également le dashboard de se surcharger de tuiles – chacune nécessitant des requêtes réseau – et de ralentir l’expérience utilisateur globale.

Concernant la durée des batch jobs, grâce à Envision nous pouvons fournir des garanties – à la compilation – qu’un batch job se terminera. Nous pouvons également garantir des temps d’achèvement largement reproductibles pour nos batch jobs. Ces garanties sont obtenues par analyse statique et conception soignée du langage Envision – qui rend possibles, en premier lieu, certaines classes d’analyses statiques. Cette approche a ses limites, mais elle est de loin supérieure aux conceptions qui n’offrent aucune garantie.

Cependant, la latence de bout en bout n’est pas entièrement sous notre contrôle. Par exemple, nous ne contrôlons pas la qualité de la connexion internet utilisée par nos clients. Une grande feuille de calcul de Lokad mettra du temps à être téléchargée sur un réseau à faible bande passante.

2.3 Avez-vous des journaux d’audit de performance du système ?

Oui. Nous collectons des journaux de performance très granulaires pour toutes les ressources informatiques impliquées : CPU, mémoire, stockage, bande passante, etc. Ces journaux sont utilisés, entre autres, pour s’assurer qu’une nouvelle version non encore publiée de la plateforme répond à nos attentes en matière de performance. Nous testons cela en comparant la performance de la nouvelle version à celle des versions précédentes, comme en témoignent ces journaux.

2.4 Est-il possible de surveiller les réponses lentes ou la congestion ?

Oui. La plateforme Lokad est dotée d’un planificateur interne capable de suivre l’exécution en temps voulu des batch jobs. La conception de Lokad assure en grande partie une réponse en temps constant pour toutes les requêtes – à l’exception des opérations de longue durée, qui sont traitées comme des batch jobs.

Comme Lokad est une plateforme multi-tenant, une grande partie de la surveillance de la performance n’est pas directement accessible à nos clients (puisqu’elle couvre la performance de la plateforme dans son ensemble). Comme on peut s’y attendre, les équipes de Lokad surveillent en continu la performance de notre plateforme.

2.5 Disposez-vous de load balancers ?

Oui. Les load balancers de Lokad sont principalement destinés à la fiabilité plutôt qu’à la performance. L’équilibrage de charge au niveau du réseau est effectué via la couche réseau de la plateforme cloud que nous utilisons (Microsoft Azure). Cependant, la répartition de la charge de traitement interne des données, telle que gérée par la plateforme Lokad, n’est pas assurée par des load balancers, mais par un orchestrateur interne associé à notre pile de compilateur.

2.6 Mutualisez-vous des ressources telles que les connexions DB, les sessions, etc.?

Oui. Cependant, la plateforme Lokad ne repose pas sur une base de données transactionnelle pour fonctionner. Ainsi, il n’y a pas de connexions DB à mutualiser. Néanmoins, nous mettons en commun de nombreuses autres ressources, chaque fois que cela a du sens d’un point de vue performance.

2.7 Supportez-vous le traitement parallèle ?

Oui. Envision (notre DSL) est conçu autour de la notion d’exécution parallélisée automatique. La plateforme Lokad exploite activement la parallélisation à plusieurs niveaux : au niveau des cœurs CPU grâce aux opérations SIMD (Single Instruction/Multiple Data) ; au niveau du CPU via des exécutions multi-threadées ; et au niveau du cluster par le biais de l’informatique distribuée. Comme le traitement parallèle est un aspect fondamental du design d’Envision, la quasi-totalité des charges de travail exécutées sur la plateforme Lokad bénéficie, par défaut, d’une parallélisation étendue, sans effort spécifique de la part de nos clients ou de nos Supply Chain Scientist.

2.8 Supportez-vous la mise en cache de données fréquemment consultées ?

Oui. Cependant, la mise en cache est souvent introduite comme solution de contournement pour pallier les limitations de performance des bases de données transactionnelles. Étant donné que la plateforme Lokad n’inclut pas de bases de données transactionnelles, nous n’utilisons pas la mise en cache à cette fin.

2.9 Compressez-vous les données pour réduire le trafic réseau ?

Oui, nous compressons la majeure partie du trafic réseau. Cependant, nous ne pouvons pas tout compresser, car cela présenterait une vulnérabilité de sécurité connue sous le nom de BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext). BREACH se produit lorsqu’une combinaison de 3 facteurs est présente.

1. Une réponse est compressée.

2. Une réponse contient un secret.

3. Une réponse contient une chaîne de caractères qui peut être récupérée par l’attaquant en élaborant la requête.

Afin de se défendre contre BREACH, Lokad désactive la compression sur toutes les réponses où la troisième condition est vraie. Nous compressons également les données pour des raisons autres que la réduction du trafic réseau ; premièrement, pour réduire les coûts de stockage des données ; et deuxièmement, pour réduire les délais de calcul.

2.10 Réalisez-vous des tests de performance ?

Oui. Lokad dispose d’une couche d’instrumentation automatisée extensive axée sur la performance. Cette série d’outils nous permet d’évaluer, avant chaque release, l’écart de performance de la prochaine version par rapport à celle actuellement déployée. Cet outil nous permet de reproduire les mêmes charges de travail, telles qu’observées en production, et de surveiller la performance résultante ; non seulement en temps réel, mais en prenant en compte toutes les ressources informatiques pertinentes (mémoire, bande passante, I/O, CPU, etc.).

2.11 Surveillez-vous la performance au niveau des transactions ?

Oui. Cependant, comme la plateforme Lokad n’utilise pas de base de données transactionnelle, il n’y a pas de “transactions” à surveiller (au sens traditionnel). L’équivalent le plus proche est l’exécution des scripts Envision. Pour ces scripts, nous surveillons la performance à un niveau très granulaire, ce qui revient à examiner de près les détails de l’exécution du plan de requête (dans une perspective de base de données transactionnelle).

Voir Authorization 3.6 et Logging and Monitoring 5.3 dans notre documentation Security pour plus d’informations sur les “transactions” dans la solution Lokad.

2.12 Quel est l’impact sur la performance d’avoir des utilisateurs simultanés sur la solution ?

Presque aucun. Le design de Lokad garantit que les dashboards peuvent être servis en temps constant même pour un grand nombre d’utilisateurs (selon les standards B2B). Cette approche contraste fortement avec de nombreuses architectures alternatives, notamment les bases de données transactionnelles et les cubes de Business Intelligence.

Cependant, étant donné qu’un utilisateur individuel pourrait (s’il possède les droits système appropriés) déclencher des charges de travail arbitrairement élevées, le nombre d’utilisateurs simultanés est, au mieux, une préoccupation secondaire en ce qui concerne la performance de la solution. En ce qui concerne l’optimisation prédictive de supply chain, les batch jobs utilisés pour réaliser les analyses d’intérêt représentent plus de 99 % de la charge de travail. Le reste, inférieur à 1 %, est dédié au traitement des demandes des utilisateurs.

2.13 Le système est-il conçu pour monter en charge verticalement et horizontalement ?

Oui. De notre point de vue, la montée en charge verticale et horizontale sont complémentaires, et la conception de la plateforme Lokad exploite les deux. L’orchestrateur interne – celui en charge de la parallélisation – commence généralement par une montée en charge verticale, celle-ci facilitant grandement la colocalisation des données. Ensuite, l’orchestrateur fait appel à une montée en charge horizontale si la charge de travail est suffisamment élevée pour bénéficier d’une exécution sur plusieurs machines.

2.14 Effectuez-vous une mise à l’échelle automatique du calcul et du stockage selon les besoins ?

Oui. La plateforme Lokad est multi-tenant. Grâce à la multi-tenance, nous réalisons des allocations de ressources de calcul à grande échelle avec une faible latence. Cela signifie que la mise à l’échelle automatique du calcul proposée par Lokad est d’ordres de grandeur plus rapide que le déploiement de grandes VMs (machines virtuelles) par un fournisseur cloud. La mise à l’échelle automatique du stockage est en grande partie assurée en tirant parti des propriétés d’auto-scalage du magasin persistant de clés-valeurs, tel que fourni par la plateforme cloud sous-jacente (Microsoft Azure).

2.15 Comment votre application gère-t-elle les exigences du “Big Data” ?

La plateforme Lokad a été spécialement conçue pour le traitement du “Big Data”. En janvier 2023, l’ensemble de la plateforme Lokad gère environ 1 petabyte de données réparties sur l’ensemble de notre clientèle. Notre plateforme peut traiter des fichiers individuels allant jusqu’à 100GB, et nous traitons régulièrement des tables comportant des dizaines de milliards de lignes. Go to Security of Lokad 4.10

Ce point est particulièrement technique et va au-delà du cadre de ce document. Pour une explication détaillée, nous recommandons la série en 4 parties de Victor Nicollet sur la conception de la machine virtuelle Envision.

2.16 La solution cloud de Lokad peut-elle être configurée en tenant compte de contraintes strictes de bande passante et de latence (côté client) ? Par exemple : bande passante = 3Mbps (téléchargement) / 1Mbps (upload), latence = 600-800ms

Oui, la webapp conçue par Lokad a été pensée pour supporter des scénarios où la connectivité est “faible” (tant en termes de bande passante que de latence). Ces préoccupations sont principalement traitées par des choix fondamentaux de conception technologique. Ces choix de conception architecturale distinguent également Lokad du courant dominant. Les problèmes de bande passante sont abordés de deux manières. Premièrement, nous sommes parcimonieux en ce qui concerne les composants JavaScript tiers. Nous disposons de moins de 1MB d’assets à récupérer initialement. Deuxièmement, la plateforme offre un contrôle total sur la quantité de données à inclure dans un dashboard unique. Ainsi, si la connectivité est faible, il est possible de rendre le dashboard suffisamment “léger”. Concernant la latence, nos dashboards ont été conçus pour regrouper toutes les données pertinentes en une unique requête HTTP. Cela minimise la friction subie par les utilisateurs finaux en situation de faible latence.

2.17 Quelles sont les capacités moyennes et maximales de débit de données de la solution comparées à une référence de 1 (bas de gamme) et 5 (haut de gamme) messages par seconde ?

The plateforme Lokad n’opère pas avec des messages. De même, les interactions avec la plateforme Lokad ne se font pas par messages. Cependant, le débit compte pour traiter rapidement d’immenses ensembles de données transactionnelles. La plateforme Lokad gère, en agrégat, plus d'1 pétaoctet de données. Nous traitons régulièrement plus d'1 téraoctet par minute pour de grands lots de calculs.

Un débit très élevé est important pour éviter tout retard opérationnel lors du traitement d’ensembles de données très volumineux (des dizaines de téraoctets) avec des calculs complexes comportant des étapes de machine learning et d’optimisation mathématique.

2.18 Quelle taille de messages la solution peut-elle gérer ? Veuillez fournir des détails concernant les valeurs minimale, maximale et moyenne.

La plateforme Lokad n’opère pas avec des messages. La chose la plus proche serait “flat files”. Ces flat files peuvent être envoyés vers - et récupérés depuis - Lokad. La plateforme Lokad peut traiter des fichiers d’une taille individuelle allant jusqu’à 100GB. Cependant, ce n’est pas une pratique recommandée car c’est généralement un peu encombrant (non pas pour Lokad, mais pour les clients qui devront se familiariser avec des outils externes pour produire et consommer ces fichiers volumineux).

3. Incidents

3.1 Quel est le processus pour qu’un client signale un incident ?

La plupart de nos clients bénéficient d’un forfait qui inclut l’accès à notre équipe de Supply Chain Scientists. Ces Supply Chain Scientists sont le premier point de contact pour signaler un incident. En cas d’incident, nous suggérons aux clients de téléphoner directement à leur Supply Chain Scientist - si le problème est urgent - ou d’envoyer un email. Les Supply Chain Scientists gèrent la gestion des incidents, y compris les escalades au sein de l’organisation de Lokad.

3.2 Offrez-vous un système de ticketing ?

Oui. Lokad exploite un système de ticketing tiers. Cependant, depuis janvier 2023, nous avons commencé à développer une solution interne qui offre une intégration étroite avec le reste de notre plateforme.

3.3 Prenez-vous en charge le signalement d’incidents vers des outils tiers ?

Oui, sous réserve d’un accord contractuel dédié.

Dans le contexte de l’optimization prédictive de la supply chain, “incidents” peuvent varier et être difficiles à définir. En général, nos clients ne considèrent pas les événements mineurs au niveau de la plateforme (comme de petites coupures) comme des “incidents”. Ce sont plutôt des bizarreries réelles de la supply chain - qui peuvent ou non refléter des problèmes avec les scripts Envision implémentés dans le compte client - qui constitueront de meilleurs candidats. Les départements informatiques externes sont rarement impliqués dans la résolution de ces incidents.

3.4 Comment assurez-vous une haute disponibilité ?

Lokad est devenu un précurseur (vers 2010) des plateformes de cloud computing précisément pour garantir une disponibilité plus élevée. Outre la redondance de l’infrastructure (voir Incidents 3.5), la conception de la solution Lokad met fortement l’accent sur la simplicité. Par rapport à des solutions logicielles d’entreprise comparables, nous avons significativement moins de dépendances complexes (quasiment d’un ordre de grandeur). Une couche énorme de complexité absente de notre solution est une base de données transactionnelle. En ayant moins de pièces mobiles, nous avons beaucoup moins de modes de défaillance, ce qui nous aide à maintenir une haute disponibilité pour nos clients (qui sont répartis sur plusieurs fuseaux horaires).

3.5 Disposez-vous d’une infrastructure redondante (si oui, comment) ? Évitez-vous les points de défaillance uniques ?

Oui. Nos systèmes critiques sont redondants, précisément pour éviter les points de défaillance uniques. Les systèmes redondants incluent les sous-systèmes qui prennent en charge des protocoles à état comme SFTP. De plus, le stockage des données n’est pas seulement redondant, il est également redondant géographiquement. Cette redondance est exploitée lors de nos mises à jour pour préserver le temps de disponibilité pendant le déploiement.

3.6 Comment récupérez-vous des défaillances matérielles ?

La récupération de la plupart des défaillances matérielles est effectuée de manière transparente par la plateforme de cloud computing que Lokad utilise. La redondance intégrée de la plateforme Lokad garantit que les défaillances matérielles momentanées n’affectent pas le temps de disponibilité pendant que la plateforme de cloud computing réaffecte une nouvelle ressource non défectueuse. Pour le stockage persistant des données, Lokad n’exploite que des services (c’est-à-dire des key-value stores) qui sont eux-mêmes protégés contre les défaillances matérielles grâce à leurs propres couches de redondance.

3.7 Disposez-vous d’une sauvegarde ?

Oui. Nous disposons d’un environnement de sauvegarde dédié aux scénarios de reprise après sinistre sévères (au-delà d’une indisponibilité au niveau du data center). Cet environnement de sauvegarde est complètement isolé de l’environnement de production. L’environnement de sauvegarde peut lire à partir de l’environnement de production (mais pas écrire), tandis que l’environnement de production ne peut ni lire ni écrire à partir de l’environnement de sauvegarde.

3.8 Disposez-vous d’un plan de reprise après sinistre ?

Oui. Au niveau technique, le plan de reprise après sinistre couvre la réinstanciation complète de la plateforme Lokad. Cette partie exploite largement les processus automatisés que nous avons mis en place pour nos mises à jour hebdomadaires. Au niveau commercial, le plan de reprise après sinistre inclut la prise de contact avec chacun de nos clients, suivant généralement un processus convenu avec chacun d’eux. Pour la plupart de nos clients, les Supply Chain Scientists désignés agissent en tant que points de contact principaux pendant toute la durée de la reprise.

3.9 La solution prend-elle en charge la récupération à un moment donné (PITR) pour la base de données et les données en dehors de celle-ci ? Quel est l’objectif de point de récupération (RPO) de la solution ?

La solution Lokad offre une conception de protection continue des données grâce à la sauvegarde incrémentielle en direct à la fois de son event store et de sa source de contenu. Par conséquent, nous pouvons effectuer une récupération à un moment donné (jusqu’au niveau de la minute).

Nous avons un RPO de 1 minute pour les sinistres au niveau du data center - si les données ne sont pas compromises. Nous y parvenons en exploitant des écritures géographiquement redondantes de notre key-value store persistant. Si le key-value store est compromis, Lokad se rétablit à partir de son stockage de sauvegarde (conservé aussi isolé que possible de nos systèmes de production), également hébergé dans un lieu géographique différent. Dans ce cas, nous avons un RPO de 12 heures.

3.10 La solution est-elle capable de générer des alertes de violation d’intégrité ? La solution dispose-t-elle de la capacité d’ajouter ou d’étendre les contrôles d’intégrité selon les besoins ?

Oui, bien que ce type de problème reflète principalement une conception logicielle basée sur une base de données transactionnelle. La plateforme Lokad n’opère pas avec une base de données transactionnelle, mais avec un event store, adoptant une conception d’event sourcing plutôt qu’une conception relationnelle. Cela n’élimine pas la nécessité de faire respecter l’intégrité des données, mais ces aspects sont abordés par d’autres moyens.

En ce qui concerne le traitement des données des clients, Envision (le DSL de Lokad) dispose de capacités étendues visant à vérifier leur qualité. Grâce à Envision, il est possible de vérifier l’intégrité et de générer des alertes. Cette logique peut être étendue ou modifiée de toute manière jugée appropriée par le client.

3.11 Les sauvegardes sont-elles testées périodiquement pour assurer une restauration correcte des données ?

Oui. La conception d’event sourcing de Lokad, combinée à son content-addressable store, rend le test de la fonctionnalité de sauvegarde et de restauration des données bien plus simple que pour la plupart des conceptions traditionnelles qui exploitent des bases de données relationnelles (comme SQL).

Voir aussi Incidents 3.7.

3.12 Les plans de reprise après sinistre sont-ils testés périodiquement pour assurer leur bon fonctionnement lors d’une reprise après sinistre ?

Oui. La stratégie de déploiement de Lokad s’appuie sur des scripts automatisés de bout en bout, limitant délibérément les interventions humaines - à l’exception notable de la possibilité de déclencher un redéploiement complet en production. Cette approche fortement automatisée facilite le test de la fonctionnalité de reprise après sinistre.

Voir Incidents 3.8.

3.13 La reprise peut-elle être effectuée pour des clients individuels et/ou des environnements clients ?

Oui. Nos outils internes permettent de restaurer le compte d’un client sélectionné (y compris la restauration du compte/environnement à un moment donné). Cependant, étant donné que la plateforme Lokad elle-même dispose de capacités de versionnage étendues (par exemple, les scripts Envision sont versionnés, et des versions antérieures sont accessibles depuis l’application), cette fonctionnalité est rarement utilisée.

3.14 Les plans de sauvegarde et de reprise après sinistre répondent-ils aux exigences RTO (Recovery Time Objective), RPO (Recovery Point Objective) et aux scénarios de sinistre des clients (tels que définis et convenus avec chaque client) ?

Oui. Le Recovery Time Objective (RTO) fait référence ici à la durée pendant laquelle la plateforme Lokad pourrait être théoriquement hors service sans causer de dommages significatifs au client, ainsi qu’au temps nécessaire pour restaurer la plateforme et ses données afin qu’elle puisse reprendre ses opérations normales après un incident majeur.

Le RTO dépend fortement des détails spécifiques aux processus supportés/fournis par Lokad. Par exemple, un client qui s’appuie sur Lokad pour planifier des commandes d’achat mensuelles à l’étranger peut avoir un RTO d'1 semaine. En revanche, un client qui s’appuie sur Lokad pour optimiser sa répartition quotidienne des stocks depuis un entrepôt vers plusieurs magasins peut avoir un RTO d'1 heure.

En pratique, diverses mesures de contingence techniques peuvent être mises en place pour améliorer substantiellement le RTO (c’est-à-dire diminuer une indisponibilité théorique). Par exemple, des décisions de basculement peuvent être calculées à l’avance. Ces décisions peuvent être utilisées en cas d’indisponibilité de la plateforme Lokad. Par rapport aux décisions optimisées “régulières”, les décisions de basculement peuvent présenter une performance supply légèrement dégradée étant donné qu’elles (par définition) ne tireraient pas parti des données absolues et les plus récentes.

Pour nos comptes gérés, il incombe au Supply Chain Scientist de Lokad d’élaborer conjointement un processus - avec les équipes opérationnelles du client - qui offre un RTO élevé, tout en garantissant également un impact commercial minimal en cas d’incident réel. De notre point de vue, ce défi est avant tout un problème de supply chain et non un problème informatique.

Voir aussi Incidents 3.9.

3.15 Si un défaut est non reproductible dans l’environnement de test, est-ce que Lokad peut vérifier que le défaut s’est produit à partir des logs et des données de support, et garantir que le défaut est corrigé conformément au Service Level Agreement (SLA) ?

Oui, les défauts peuvent être reproduits dans nos environnements. La reproductibilité stricte de tous les états de données et de tous les calculs est un principe de conception fondamental de la plateforme et de l’architecture de Lokad. Par exemple, le système de fichiers au sein de la plateforme Lokad est entièrement versionné (comme Git), précisément pour répondre à cette préoccupation.

Il convient de noter que les logs sont plus efficaces pour dépanner des problèmes trivials, tels que des coupures de serveur. Lorsqu’il s’agit de résoudre des problèmes complexes et des défauts dans un environnement de données à grande échelle - où des téraoctets de données sont impliqués - les logs sont souvent insuffisants.

Ainsi, bien que Lokad conserve et consulte les logs lorsque cela est approprié, nous ne nous fions pas aux logs pour traiter les défauts ou vérifier qu’ils ont été corrigés. Au lieu de cela, nous tirons principalement parti de choix de conception supérieurs pour offrir une meilleure visibilité, traçabilité et reproductibilité.

Ces choix de conception délibérés nous permettent d’identifier, de reproduire et de corriger les défauts d’une manière que se fier uniquement aux logs ne permettrait pas.

Veuillez consulter Architecture of Lokad pour une analyse détaillée des plusieurs choix de conception clés que nous adoptons afin d’éviter des catégories entières de problèmes logiciels courants.

3.16 Conservez-vous des enregistrements de toutes les demandes de service et appels de service (y compris la catégorie de chaque appel) effectués par la société cliente ? Les enregistrements incluent-ils : l’identité de la personne appelante et de la personne appelée ; la nature de l’erreur, du problème ou de l’incident signalé ; le temps de réponse de Lokad ; la disposition de l’appel de service ; la résolution ; les temps de résolution ; et la disponibilité du système ?

Oui, la plateforme Lokad dispose de fonctionnalités de gestion de tâches/tickets/problèmes qui fournissent les détails énumérés.

Concernant les “résolutions”, il convient de noter que la Supply Chain Quantitative de Lokad (QSC) consiste à trouver le compromis le plus avantageux financièrement lorsqu’un problème se présente. La QSC n’est pas, techniquement, une approche de “résolution de problèmes”, car les problèmes de supply chain ne sont pas vraiment “résolus”, ils sont atténués en effectuant des compromis éclairés financièrement.

En bref, Lokad dispose des outils et des processus pour résoudre rapidement les “problèmes faciles” (comme les coupures de serveur) de manière simple. Lorsqu’il s’agit des problèmes de supply chain plus importants et conséquents (tels que l’allocation des stocks de détail ou les problèmes de réapprovisionnement des stocks), il s’agit généralement de discussions plus ouvertes et continues avec les clients concernant les compromis qui maximisent leur retour sur investissement.

4. Architecture

4.1 Quels langages de programmation utilisez-vous ?

La plateforme Lokad est développée en C#, F# et TypeScript. La plateforme intègre également Envision (le DSL de Lokad), qui est utilisé pour implémenter les solutions spécifiques de supply chain pour les clients.

4.2 Quelle suite de développement utilisez-vous ?

Les équipes d’ingénierie logicielle de Lokad utilisent Microsoft Visual Studio. Les équipes de Supply Chain Scientists utilisent la plateforme Lokad elle-même, qui intègre sa propre suite de développement.

4.3 Quels systèmes d’exploitation supportez-vous ?

Lokad est une plateforme web et nous supportons tous les systèmes d’exploitation disposant d’un accès à un navigateur web moderne (ex: Firefox). En interne, la plateforme Lokad est compatible à la fois avec Linux et Microsoft Windows, bien que tous nos systèmes de production soient déployés sous Linux (Ubuntu).

4.4 Quel système de base de données utilisez-vous ou supportez-vous ?

Lokad supporte tous les systèmes de bases de données capables de produire des exportations de flat files. Cela inclut pratiquement tous les systèmes de bases de données du marché, y compris les modèles plus anciens. En interne, Lokad n’utilise pas de système de base de données, mais un key-value store. Au moment de la rédaction (janvier 2023), nous utilisons Blob Storage tel que fourni par Microsoft Azure.

4.5 Quel système de mise en cache utilisez-vous ?

Lokad a conçu ses propres sous-systèmes de mise en cache en C#/.NET. Ces sous-systèmes sont étroitement intégrés au reste de la solution et ne correspondent pas aux systèmes de mise en cache traditionnels principalement destinés à atténuer les problèmes de performance d’une base de données relationnelle (que Lokad ne possède pas).

4.6 Comment la solution gère-t-elle les certificats ?

Lokad exploite Let’s Encrypt through les renouvellements automatisés de certificats.

4.7 Quels sont les prérequis techniques pour utiliser la solution ?

La principale condition technique préalable est un système de transaction qui assure le suivi de ses stocks. De plus, il est utile que le client ait une certaine expérience dans l’extraction de données (sous forme de fichiers plats) de ses systèmes transactionnels, mais ce n’est certainement pas une condition préalable.

4.8 Listez toutes les licences tierces supplémentaires requises pour faire fonctionner la solution de Lokad (par ex., OS, SQL,…).

N/A. Lokad ne requiert aucune licence tierce pour fonctionner. Un large éventail d’outils open-source existe pour prendre en charge l’intégration de Lokad (c’est-à-dire des fichiers plats transférés via FTPS ou SFTP) ; par conséquent, aucune licence tierce n’est requise, même indirectement, pour bénéficier de la plateforme de Lokad.

4.9 Le service nécessite-t-il des plug-ins de navigateur ou un logiciel spécial ?

Lokad est une application web. Elle ne nécessite pas de plug-ins de navigateur ni de logiciel spécial.

4.10 Quelles sont les interfaces entrantes et sortantes de l’application ?

La solution de Lokad offre une interface web - accessible via HTTPS - et des protocoles de fichiers, à savoir SFTP et FTPS.

4.11 Comment vous assurez-vous qu’il n’y ait pas de fuites de données entre les tenants ?

La solution de Lokad segmente les données des tenants grâce à son architecture même, ce qui garantit qu’aucune fuite de données (même accidentelle) ne se produise. De plus, tout code déployé en production fait l’objet d’une révision par les pairs, fournissant ainsi une couche de protection supplémentaire. Enfin, nous demandons aux chercheurs en sécurité (personnes effectuant des tests d’intrusion) d’examiner spécifiquement la possibilité de fuites de données. Nous leur donnons accès à plusieurs comptes Lokad - dans un environnement dédié et entièrement isolé qui reproduit celui de la production - afin qu’ils puissent vérifier de manière approfondie cette propriété de notre plateforme.

4.12 La solution peut-elle être containerisée ?

Oui, mais il y a peu ou pas d’avantage à containeriser la plateforme de Lokad. La containerisation apporte de la valeur lorsqu’il existe des dépendances complexes (par exemple, une base de données transactionnelle, un système de cache isolé, etc.). Nous n’utilisons pas de conteneurs en production ou en développement, ce qui améliore notre sécurité en éliminant des catégories entières de vulnérabilités. À la place, nous gardons la solution suffisamment simple pour que le déploiement puisse être effectué même avec de petits scripts shell.

4.13 Les composants de l’interface graphique peuvent-ils être découplés du backend ?

Oui, les composants de l’interface graphique (dans ce cas, les interfaces web) sont autonomes. Cette conception aide à atteindre une plus grande disponibilité. Les utilisateurs finaux peuvent accéder aux tableaux de bord de leur compte Lokad même en cas de panne soudaine affectant l’un des autres sous-systèmes.

4.14 L’application Lokad prend-elle en charge les fonctions de localisation (comme le changement de langue) ?

Oui, l’application prend en charge les fonctions de localisation. Toutes les interfaces utilisateur produites par la plateforme de Lokad peuvent être localisées dans n’importe quelle langue. En particulier, l’ensemble de la pile technologique adopte l’UTF-8, afin de prendre en charge tous les jeux de caractères qui existent au-delà du latin. En particulier, toute interface utilisateur produite par la plateforme de Lokad peut être re-localisée - après livraison - dans une autre langue.

4.15 Est-il possible pour les utilisateurs finaux de mettre à jour ou de créer de nouvelles traductions après la livraison des données post-traitées de Lokad ?

Oui, voir 4.14 ci-dessus.

4.16 Votre système dispose-t-il d’une aide intégrée ? Si oui, dans quelle(s) langue(s) ?

Oui, Lokad est livré avec une documentation publique très complète (en anglais). Toutefois, l’utilisation de la plateforme Lokad implique la création d’interfaces utilisateur sur mesure et notre processus habituel inclut au moins deux formes de documentation ou d’assistance.

Premièrement, les tableaux de bord conçus dans la solution Lokad sont destinés à être documentés contextuellement - directement depuis le tableau de bord lui-même. En particulier, nous disposons même d’une tuile Markdown dédiée à la documentation en texte enrichi. Deuxièmement, nos livrables incluent un “Manuel de Procédure Conjointe”. Dans l’ensemble, le manuel fournit une analyse détaillée non seulement de la mécanique de la solution, mais également des raisons pour lesquelles chaque élément a été sélectionné (et comment il satisfait aux besoins spécifiques en supply chain du client).

4.17 L’application web est-elle responsive ?

L’application web de Lokad, ainsi que ses supports (tel que la documentation technique), a été conçue pour être responsive. Cependant, certaines fonctionnalités avancées, comme l’édition de code, sont impraticables sur les appareils mobiles et/ou tablettes. Ainsi, le design est destiné à maximiser la réactivité pour les activités prévues sur PC et appareils plus petits, respectivement.

4.18 Si votre système est une application web, quels navigateurs et quelles versions supportez-vous ? Quelle est votre norme minimale pour les navigateurs internet ?

Lokad est une application web et nous supportons les principaux navigateurs web “evergreen” tels que Chrome, Firefox et Safari. Nous n’essayons pas de supporter les anciens navigateurs pour des raisons de sécurité, car supporter ces navigateurs met implicitement en danger nos client(s). En d’autres termes, un navigateur vulnérable peut être exploité par un acteur malveillant pour extraire des données. Cela dit, nous sommes également assez conservateurs en ce qui concerne les nouvelles capacités des navigateurs. En règle générale, nous évitons de supporter toute capacité de navigateur qui n’a pas été adoptée par tous les principaux navigateurs web depuis au moins un an.

4.19 Pour les applications mobiles et tablettes, quels OS (et versions) Lokad supporte-t-il ?

N/A. Étant donné que Lokad est une application web proposée en SaaS, nos clients ne se préoccupent pas du support des OS. En interne, Lokad est développé sous Windows, tandis que tout notre environnement de production hébergé dans le cloud est sous Linux. Ainsi, nous sommes assez confiants quant à la large portabilité de la solution Lokad. Bien que nous ne ressentions actuellement aucun besoin de modifier cette configuration, si des preuves valables devaient se présenter, nous nous adapterions en conséquence.

4.20 L’application web de Lokad peut-elle fournir des notifications aux utilisateurs finaux ? Si oui, quelle technologie/protocole est utilisée ?

Oui, Lokad a la capacité d’envoyer des notifications via des hooks HTTP programmables. Ces hooks peuvent être utilisés pour recourir à un système tiers, souvent déjà en place dans l’entreprise cliente, afin d’envoyer une notification par e-mail ou tout autre type de notification jugé approprié. Les hooks sont également généralement utilisés pour signaler la disponibilité de données à récupérer depuis la plateforme de Lokad via SFTP ou FTPS.

4.21 Existe-t-il des éléments partagés dans la solution qui sont communs à tous les clients (comme les fonctions de surveillance, les solutions de sauvegarde ou de gestion de correctifs, etc.) ?

Oui, comme Lokad est une application multi-tenant, les capacités au niveau de l’infrastructure sont partagées entre les tenants, c’est-à-dire les comptes clients. Cela inclut la surveillance de la disponibilité, des performances et pour des raisons de sécurité, la sauvegarde, la gestion de correctifs, les mises à niveau, etc.

4.22 La solution permet-elle une fonctionnalité de messagerie à destinations multiples (c’est-à-dire la capacité d’envoyer un message à plus d’un destinataire ou application) ?

La plateforme de Lokad ne fonctionne pas avec des messages. Cependant, nous fournissons des capacités de hooks HTTP qui peuvent être utilisées pour générer des notifications de messages arbitrairement complexes, généralement par le biais de systèmes tiers à faible coût. Ces notifications sont parfois utilisées par les équipes supply chain pour surveiller l’achèvement en temps voulu des lots de calculs cruciaux pour les missions avec la plateforme de Lokad.

4.23 Tous les systèmes et composants critiques utilisent-ils la même source de temps (NTP) ou synchronisent-ils leurs horloges d’une manière fiable ?

Oui. Lokad utilise le service NTP par défaut fourni avec Ubuntu - ntp.ubuntu.com. Plus précisément, ntpd est utilisé comme service de synchronisation temporelle, qui se synchronise avec une source de temps NTP externe accessible via le réseau.

4.24 Existe-t-il une liste d’inventaire des actifs ou une base de données de gestion de la configuration (CMDB) ?

Oui, nous disposons d’un logiciel de gestion des actifs informatiques pour soutenir nos processus. Cette plateforme nous aide à maintenir une liste d’inventaire des actifs complète et sert de base de données de gestion de la configuration (CMDB). Grâce à ce système, nous pouvons suivre, gérer et allouer efficacement les actifs matériels et logiciels à travers l’organisation. Nos équipes ont la capacité d’identifier rapidement le statut, l’emplacement et la configuration de tout actif, garantissant ainsi des réponses rapides aux changements, mises à jour ou problèmes éventuels.

De plus, notre outil offre des fonctionnalités permettant une gestion détaillée du cycle de vie, garantissant que les actifs soient catalogués avec précision depuis leur acquisition jusqu’à leur fin de vie. Des capacités d’audit automatisé, associées à des fonctionnalités de reporting détaillé, assurent que nous conservions une visibilité et un contrôle complets sur notre environnement IT, facilitant la conformité et une allocation efficace des ressources.

4.25 Chaque connexion à un réseau externe est-elle terminée par un pare-feu (par ex., Internet, réseaux partenaires) ?

Non, nous ne terminons pas chaque connexion à un réseau externe par un pare-feu, que ce soit l’Internet ou les réseaux partenaires. Notre décision repose sur des préoccupations réelles concernant l’efficacité et les implications de telles mesures.

De notre point de vue, bien que les pare-feu soient généralement considérés comme une défense de première ligne, ils peuvent ironiquement élargir la surface d’attaque. Plus nous intégrons de composants et de systèmes, plus nous introduisons de faiblesses potentielles. Les pare-feu, en raison de leur nature, fonctionnent comme des processus à haut privilège. Cela signifie qu’ils deviennent des cibles principales pour les cyber-attaques, et lorsqu’ils sont compromis, les conséquences peuvent être dévastatrices. Un exemple illustratif est l’attaque SolarWinds, où les systèmes mêmes destinés à protéger l’information ont été exploités, entraînant des violations significatives.

De plus, la présence de pare-feu stricts peut être contre-productive dans un sens pratique. Notre expérience a montré que de tels systèmes incitent souvent les employés à chercher des moyens alternatifs pour accéder et partager des informations. Cela implique généralement de contourner complètement le réseau d’entreprise (empêchant ainsi toute surveillance), en utilisant des connexions 4G ou 5G personnelles depuis leurs propres appareils. Ces pratiques augmentent involontairement le risque de failles de sécurité et de fuites de données.

Ainsi, bien que nous soyons profondément engagés en matière de sécurité, notre approche est holistique et guidée par des préoccupations pratiques plutôt que de se fier uniquement aux mesures traditionnelles.

4.26 Le réseau dispose-t-il d’un environnement DMZ qui transmet, traite ou stocke des systèmes critiques (comme les serveurs web, DNS, services d’annuaire et accès à distance), ainsi que des données client ?

Non, Lokad n’utilise pas un environnement DMZ traditionnel au sein de son réseau pour transmettre, traiter ou stocker des systèmes critiques et des données clients. À la place, nous avons adopté une approche zéro trust en matière de sécurité réseau.

Ce modèle ne repose pas sur les DMZ, mais fonctionne selon le principe de “ne jamais faire confiance, toujours vérifier.” Chaque demande d’accès est validée et authentifiée, quelle que soit son origine, qu’elle provienne de l’intérieur ou de l’extérieur de l’organisation.

Cela assure une posture de sécurité plus robuste et holistique, car elle ne dépend pas de défenses périmétriques telles qu’une DMZ, mais se concentre plutôt sur la sécurisation de chaque point d’accès individuel et de chaque transaction de données. Nous croyons que l’approche zéro trust offre une protection supérieure pour nos systèmes critiques et les données clients.