FAQ: Informatique (IT)

L’application Lokad est une application web fournie en tant que 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’application Lokad est conçue comme une couche analytique qui fonctionne aux côtés des systèmes transactionnels (ERP, WMS, CRM, etc.). Elle est proposée avec un forfait mensuel qui regroupe généralement l’application elle-même avec des services professionnels. Ces services professionnels, fournis par les ingénieurs de Lokad (Supply Chain Scientists), éliminent presque entièrement le besoin de support technique du service informatique lui-même pour ce domaine. La contribution clé attendue du service informatique est la configuration d’un pipeline de données poussant des fichiers plats (par SFTP ou FTPS) vers Lokad, et potentiellement réintégrant les résultats générés.

Public cible : Le service informatique
Dernière modification : 30 novembre 2023

Aperçu technique

L’application Lokad est multi-locataire. Chaque locataire (c’est-à-dire compte client) dispose de son propre système de fichiers dédié et de son propre référentiel de code dédié. Le système de fichiers est accessible via FTPS, SFTP et une interface web. Ce système de fichiers est conçu pour les gros fichiers plats (jusqu’à 100 Go par fichier) et propose une version des données (comme Git). Le référentiel de code est utilisé pour héberger des scripts Envision. Envision est un DSL (Domain Specific programming Language) propriétaire développé par Lokad. Ce DSL est fortement spécialisé pour les cas d’utilisation d’optimisation prédictive. Les scripts Envision sont utilisés pour effectuer les analyses numériques de base (y compris les algorithmes d’apprentissage automatique, les solveurs, …) et pour générer des tableaux de bord riches en données.

L’application est redéployée entièrement chaque mardi entre 10h00 et 14h00 (heure de Paris). Le temps d’arrêt est généralement inférieur à 5 minutes. Lokad prend en charge tous les aspects de la version.

Il n’est pas attendu que le service informatique acquière une compétence spécifique avec la pile technologique de Lokad. Cependant, si vous êtes curieux, il existe une documentation technique complète.

Aperçu de la contribution informatique

Nous attendons du service informatique qu’il mette en place un pipeline de données qui pousse une courte série d’extractions de fichiers plats pertinentes vers Lokad par SFTP ou FTPS. Les extractions sont effectuées sur les systèmes transactionnels (par exemple : ERP). Nous avons une forte préférence pour les extractions de tables brutes (pas de filtre, pas de jointure, pas de transformation), ce qui nécessite un effort minimal. D’un point de vue ETL, nous ne demandons que la partie ‘E’ (extraction) sous sa forme la plus simple (copie brute). En termes de format, Lokad est compatible avec tous les fichiers plats tabulaires raisonnablement.

Le pipeline de données doit fonctionner au moins quotidiennement et être entièrement automatisé. Le travail du service informatique dépend de la portée de l’extraction de données (quels systèmes ? quelles tables ?). Cependant, en règle générale, la configuration du pipeline de données nécessite environ 15 à 45 jours-homme, même pour les grandes entreprises. Une fois le pipeline de données en place, Lokad demande généralement un suivi minimal de la part du service informatique, ce qui est généralement fait avec 1 à 2 jours-homme par mois.

Aperçu de la sécurité

L’application est hébergée dans les centres de données Microsoft Azure situés dans l’UE. Nous ne traitons aucune donnée personnelle, car nous n’avons pas besoin de telles données pour fonctionner. Lors de l’établissement de la portée de l’extraction de données, nous excluons toute colonne ou champ pouvant contenir des données personnelles.

Pour l’authentification, notre préférence va à SAML. Nous recommandons vivement aux utilisateurs d’accéder à 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 effectué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 fin en soi. Cependant, en même temps, les dirigeants de la supply chain qui engagent leur entreprise dans une initiative de Supply Chain Quantitative nécessitent une visibilité en ce qui concerne le calendrier du projet. Alors que des retours positifs peuvent être obtenus en quelques mois, il faut souvent jusqu’à deux ans pour débloquer pleinement le potentiel de la Supply Chain Quantitative. Dans le morceau suivant, nous fournissons un aperçu d’un calendrier typique associé à une initiative de 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 : Les représentants des deux parties se présentent mutuellement et planifient des réunions hebdomadaires. Ces réunions hebdomadaires dureront jusqu’à ce que la phase de Production soit atteinte. Le Supply Chain Scientist présente les différentes phases de mise en œuvre et les différents livrables que le client peut attendre. Le reste de l’appel est consacré à la revue de divers détails de la supply chain et des caractéristiques informatiques de l’intégration. Après l’appel, un résumé documentant les aspects organisationnels du projet est produit et envoyé au client.

Spécifications des données : Peu de temps après la réunion de lancement, le Supply Chain Scientist produit 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 d’origine telles qu’elles existent dans les systèmes informatiques du client.

1ère mise en ligne des données : Après la validation des spécifications, le premier ensemble de données est téléchargé sur les serveurs de Lokad par le client. Généralement, à ce stade, le téléchargement n’est pas encore effectué via un processus automatisé car plusieurs tentatives sont généralement nécessaires pour établir un consensus sur les détails des spécifications des données.

Validation des données : Le Supply Chain Scientist effectue une investigation approfondie du contenu de l’ensemble de données du client. En particulier, des vérifications de cohérence sont introduites pour surveiller la qualité des données selon plusieurs critères. L’objectif est de s’assurer que 1) l’ensemble de données est correctement actualisé par le processus de téléchargement, 2) l’ensemble de données reflète correctement la réalité de l’entreprise et 3) l’ensemble de données est cohérent et complet pour les besoins d’optimisation de la supply chain.

En termes de livrables, pendant 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 à des fins dépassant l’initiative de la Supply Chain Quantitative elle-même - dans le cadre de leur processus interne d’assurance qualité des données par exemple.

Audit de mi-projet : 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 d’adresser, le plus tôt possible, les problèmes qui pourraient survenir pendant 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, basé sur une liste de contrôle communiquée au client à l’avance par le Supply Chain Scientist, juste après la réunion de lancement.

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

Mise en place de l’optimisation : À partir de ce moment, le Supply Chain Scientist dispose de tous les ingrédients nécessaires pour mettre en œuvre l’optimisation des décisions qui ont été convenues avec le client précédemment. Par conséquent, il met en place des scripts pour générer différents résultats quantitatifs : suggestions d’achats opérationnels, suggestions de dispatch, etc. Les chiffres produits 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 de bord finaux et doivent être révisés conjointement avec le client.

Retours & ajustements : Les demandes du client visant à apporter des modifications ou à “ajuster” les différents résultats conduisent généralement à des ajustements des scripts rédigés par le Supply Chain Scientist. Il existe de nombreux paramètres et méthodes qui peuvent être adoptés pour aligner adéquatement les caractéristiques de la supply chain en cours d’optimisation avec la logique d’optimisation. Lorsque la méthodologie elle-même revêt une importance stratégique pour le client, cela est explicitement discuté entre le client et le Supply Chain Scientist.

Production : Après plusieurs cycles d’ajustements et de révisions, le client atteint un stade où il commence à faire confiance à la logique mise en place par le Supply Chain Scientist. À ce moment, le client peut commencer à utiliser le service en production, c’est-à-dire qu’il peut exécuter directement les décisions de la supply chain telles qu’elles ont été 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 qui garantit la maintenabilité de la solution.

Support & maintenance : La solution est opérationnelle et est utilisée par le client tandis que le Supply Chain Scientist surveille l’exécution quotidienne fluide du pipeline de données. Des appels sont régulièrement organisés entre le client et le Supply Chain Scientist pour vérifier que l’optimisation offre le degré de performance de la supply chain attendu. De plus, les supply chains ne sont pas statiques, ainsi, les changements commerciaux ou informatiques, petits ou grands, doivent être examinés : un nouveau entrepôt, un changement de marché, un nouveau processus, etc. Le Supply Chain Scientist propose des modifications adaptées pour accommoder ces différents changements. Des appels de contrôle sont planifiés avec une fréquence convenue, généralement mensuelle.

Foire aux questions (FAQ)

1. Gestion des versions

1.1 Comment fonctionnent les versions pour Lokad ?

Lokad gère toutes les versions en interne, ce qui garantit une transparence totale pour les clients. Toutes les versions susceptibles d’impact sur un client sont coordonnées avec eux - via les équipes techniques du client - bien à l’avance. En règle générale, Lokad adopte une approche prudente en matière de versions : si une version planifiée ne laisse pas suffisamment de temps de préparation pour un client, la version sera temporairement reportée.

Les versions de Lokad sont très granulaires, et la conception permet généralement au client de se désengager d’un élément technique particulier d’une version 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 version globale peut quand même avoir lieu (et mettre en œuvre les autres éléments non impactants).

1.2 À quelle fréquence sont effectuées les versions ?

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

1.3 Fournissez-vous un plan des prochaines versions ?

Oui, voir Gestion des versions 1.2.

1.4 Un changement de version nécessite-t-il une réinstallation ou juste un correctif ?

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

1.5 Combien de temps faut-il pour appliquer une version 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 le déploiement. L’opérationnalité pendant un déploiement est discutée dans Gestion des versions 1.7.

1.6 Qui est responsable de l’exécution correcte de la version ?

L’équipe de Lokad prend la pleine responsabilité de l’exécution correcte de la version.

1.7 Y a-t-il une interruption de service pendant la version ?

Principalement non, mais gardez à l’esprit que la solution de Lokad est un système distribué dédié aux calculs à grande échelle. En tant que tel, l’impact d’une version diffère entre les systèmes frontaux et arrière. Les sous-systèmes orientés client, tels que les tableaux de bord, sont conçus pour un fonctionnement sans interruption. Les systèmes en arrière-plan, tels que ceux chargés de l’exécution des travaux par lots, peuvent être mis en pause pendant quelques minutes (du moins pour certains travaux). Cependant, ces travaux par lots peuvent être planifiés, de sorte que la planification proactive devrait permettre l’achèvement des travaux par lots en dehors de la période de version.

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

Lokad utilise des processus automatisés dédiés au test et à la vérification de la correction d’une prochaine version. Ces processus comprennent des suites étendues de tests automatisés (mesurés en milliers) ; des tests unitaires, des tests fonctionnels, des tests de performance, etc. Nous avons également conçu des outils dédiés qui nous permettent de reproduire des séquences entières d’exécutions de travaux passés au sein de la plateforme Lokad. Ces outils nous permettent de vérifier que les scripts Envision ont le même comportement avant/après une prochaine version. 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 la 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 avons un environnement ’evergreen’ qui correspond à la dernière version stable de notre code source. 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 qu’une prochaine version spécifique se comporte comme prévu. Cette situation peut se produire s’il y a une intégration informatique entre Lokad et le client. En pratique, cette situation est rare.

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 “environnements”. Si l’objectif est de pouvoir effectuer tout type de test, alors un deuxième compte Lokad peut être fourni à des fins de test transitoire. Cette deuxième approche garde le compte client principal (utilisé pour la production) isolé de ces tests.

1.10 Combien de versions différentes peuvent coexister ?

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

1.11 Un client peut-il refuser une version ?

Comme Lokad est un SaaS multi-locataire qui exécute la même version unique pour tous les clients, il n’est pas possible de refuser une version. Cependant, d’un point de vue commercial, cela est sans objet car tout “changement” est mis en œuvre par l’exécution de scripts Envision au sein de la solution Lokad.

Pour les situations où une version peut être temporairement reportée, voir Gestion des versions 1.1.

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

Oui. Ces notes sont partagées en interne (avec nos équipes de scientifiques de la supply chain). Si cela est explicitement convenu dans le cadre d’un contrat, ces notes de version peuvent être rendues accessibles à un client. En pratique, les notes de version de la plateforme Lokad n’intéressent que les personnes travaillant avec du code Envision.

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

La plupart de nos clients bénéficient d’une offre “logiciel + expert”, où une équipe de scientifiques de la supply chain de Lokad est responsable de la mise en œuvre et de la maintenance de la solution de supply chain d’un client. Ces situations sont connues sous le nom de “supply chain as a service”. Dans ces arrangements, le client interagit régulièrement avec un (ou plusieurs) scientifiques de la supply chain. 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 le sens où la plateforme Lokad est par nature programmatique. La logique “analytique” de Lokad prend la forme de scripts Envision - Envision étant le DSL (Domain-Specific Language) conçu par Lokad dans le but de l’optimisation prédictive de la supply chain.

Ainsi, en un sens, chaque configuration de paramètre est disponible en exploitant les scripts Envision dans le compte.

2. Performance

2.1 Votre SLA (accord de niveau de service) couvre-t-il un temps de disponibilité de 99.xy % ?

Oui. Le SLA fait partie de notre accord contractuel par défaut. Cependant, la notion de temps de disponibilité dans le contexte d’un système informatique distribué - dédié à l’optimisation prédictive de la 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 perturber l’efficacité ordinaire de nos heuristiques d’allocation de ressources. Cela peut à son tour prolonger le temps nécessaire pour exécuter les tâches en lot de Lokad (par exemple, 75 minutes au lieu des 60 habituels). Certains pourraient considérer cela comme une période d’indisponibilité de 15 minutes, mais cela est hors de notre contrôle.

• Lokad reçoit les mêmes données client à temps, mais les données présentent une baisse importante des niveaux de stocks. Cela déclencherait une interruption des tâches en lot (côté Lokad) et alerterait un Supply Chain Scientist pour enquêter sur le problème. Le Supply Chain Scientist constate qu’une commande de réapprovisionnement automatisée est exceptionnellement importante. Le Supply Chain Scientist décide qu’une évaluation directe du client est nécessaire. Le lendemain, le client confirme que les données de stock étaient corrompues et auraient entraîné une importante dépréciation des stocks. Certains pourraient considérer cela comme une période d’indisponibilité de 24 heures, mais cela semble pratiquement obtus 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 très faux. Une fois une décision de supply chain est prise, comme (incorrectement) déclencher une production en lot, l’annuler peut être extrêmement coûteux. Nous encourageons nos clients à ne pas devenir arbitrairement attachés à des indicateurs isolés, car cette attitude peut inciter les gens à fournir un travail global de moindre qualité tant qu’il semble satisfaire un KPI (comme un temps de disponibilité de x.y %).

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

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

Nous avons conçu ce qui équivaut grossièrement à des “tableaux de bord en temps constant”. Sous le capot, l’affichage d’un tableau de bord nécessite une seule demande sur le réseau, et dans notre back-end, nous regroupons toutes les données du tableau de bord pour limiter le nombre de demandes réseau (généralement mesuré en chiffres simples). Ce choix de conception va très loin pour “garantir” la faible latence de la demande utilisateur typique dans l’affichage d’un tableau de bord. Ce choix de conception empêche également le tableau de bord de devenir encombré de tuiles - chacune nécessitant des demandes réseau - et ralentissant l’expérience utilisateur globale.

En ce qui concerne la durée des tâches en lot, à travers Envision, nous pouvons fournir des garanties - au moment de la compilation - qu’une tâche en lot se terminera. Nous pouvons également garantir des temps de fin largement reproductibles pour nos tâches en lot. Ces garanties sont obtenues grâce à une analyse statique et à une conception minutieuse du langage Envision - qui rend possible certaines classes d’analyses statiques en premier lieu. Cette approche a des limites, mais elle est largement supérieure aux conceptions qui n’offrent aucune garantie du tout.

Cependant, la latence de bout en bout n’est pas entièrement entre nos mains. Par exemple, nous ne contrôlons pas la qualité de la connexion Internet utilisée par nos clients. Un grand tableau de Lokad prendra du temps à se télécharger sur un réseau à faible bande passante.

2.3 Disposez-vous de journaux d’audit de performance 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 de performance sont utilisés, entre autres, pour garantir qu’une nouvelle version de la plateforme, pas encore publiée, répond à nos attentes en termes de performance. Nous testons cela en comparant les performances de la nouvelle version avec celles 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 qui peut suivre l’exécution en temps opportun des travaux par lots. La conception de Lokad garantit largement une réponse en temps constant pour toutes les demandes - à l’exception des opérations de longue durée, qui sont traitées comme des travaux par lots.

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

2.5 Disposez-vous de répartiteurs de charge ?

Oui. Les répartiteurs de charge de Lokad sont principalement destinés à la fiabilité plutôt qu’à des fins de performance. La répartition de charge au niveau du réseau est effectuée via la couche de mise en réseau de la plateforme de cloud computing que nous utilisons (Microsoft Azure). Cependant, la répartition de la charge de traitement des données internes, gérée par la plateforme Lokad, n’est pas gérée via des répartiteurs de charge, mais via un orchestrateur interne associé à notre pile de compilation.

2.6 Regroupez-vous des ressources telles que des connexions de base de données, des 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 de base de données à regrouper. Néanmoins, nous regroupons de nombreuses autres ressources, chaque fois que cela a du sens d’un point de vue performance.

2.7 Prenez-vous en charge 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 du cœur du CPU grâce aux opérations SIMD (Single Instruction/Multiple Data) ; au niveau du CPU grâce aux exécutions multi-thread ; et au niveau du cluster grâce à l’informatique distribuée. Comme le traitement parallèle est un aspect de conception central d’Envision, la quasi-totalité des charges de travail exécutées sur la plateforme Lokad bénéficient d’une parallélisation étendue, par défaut, sans aucun effort spécifique de la part de nos clients ou de nos scientifiques de la supply chain.

2.8 Prenez-vous en charge la mise en cache des données fréquemment consultées ?

Oui. Cependant, la mise en cache est souvent introduite comme une solution de contournement pour faire face aux 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 plupart 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 lorsque trois facteurs sont présents.

1. Une réponse est compressée.

2. Une réponse contient un secret.

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

Pour se protéger 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 retards de calcul.

2.10 Effectuez-vous des tests de performance ?

Oui. Lokad dispose d’une couche d’instrumentation automatisée orientée performance étendue. Cette série d’outils nous permet d’évaluer, avant chaque publication, la différence de performance de la version à venir par rapport à celle obtenue avec la version 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 termes de temps écoulé, mais en tenant compte de toutes les ressources informatiques pertinentes (mémoire, bande passante, E/S, CPU, etc.).

2.11 Surveillez-vous la performance au niveau de la transaction ?

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, qui est approximativement analogue à la surveillance des détails de l’exécution du plan de requête (d’un point de vue base de données transactionnelle).

Consultez Autorisation 3.6 et Journalisation et surveillance 5.3 dans notre documentation sur la Sécurité pour plus d’informations sur les “transactions” dans la solution Lokad.

2.12 Quel est l’impact sur la performance d’avoir des utilisateurs concurrents sur la solution ?

Presque aucun. La conception de Lokad garantit que les tableaux de bord peuvent être servis en temps constant même pour un grand nombre d’utilisateurs (selon les normes B2B). Cette approche est en net contraste avec de nombreuses architectures alternatives, notamment les bases de données transactionnelles et les cubes d’informatique décisionnelle.

Cependant, étant donné que tout utilisateur individuel pourrait (s’il détient les droits système appropriés) déclencher des charges de travail arbitrairement importantes, le nombre d’utilisateurs concurrents 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 la supply chain, les travaux par lots utilisés pour effectuer les analyses d’intérêt représentent plus de 99% de la charge de travail. Le reste, soit moins de 1%, est dédié à la satisfaction des demandes des utilisateurs.

2.13 Le système est-il conçu pour s’adapter verticalement et horizontalement ?

Oui. De notre point de vue, l’adaptation verticale et horizontale sont complémentaires, et la conception de la plateforme Lokad tire parti des deux. L’orchestrateur interne - celui en charge de la parallélisation - commence généralement par une adaptation verticale, car l’adaptation verticale facilite largement la colocalisation des données. Ensuite, l’orchestrateur tire parti de l’adaptation horizontale si la charge de travail est suffisamment importante pour bénéficier d’une exécution multi-machine.

2.14 Mettez-vous à l’échelle automatiquement le calcul et le stockage selon les besoins ?

Oui. La plateforme Lokad est multi-locataire. Grâce à la multi-locataire, nous effectuons des allocations à grande échelle de ressources de calcul à faible latence. Cela signifie que l’auto-scaling du calcul fourni par Lokad est des ordres de grandeur plus rapide que le démarrage de grandes VM (machines virtuelles) auprès d’un fournisseur de cloud computing. L’auto-scaling du stockage est largement effectué en tirant parti des propriétés d’auto-scaling du magasin de clés persistant, telles que fournies par la plateforme de cloud computing sous-jacente (Microsoft Azure).

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

La plateforme Lokad a été spécifiquement conçue pour le traitement des “Big Data”. En janvier 2023, l’ensemble de la plateforme Lokad gère environ 1 pétaoctet de données sur l’ensemble de notre base de clients. Notre plateforme peut traiter des fichiers individuels allant jusqu’à 100 Go, et nous traitons régulièrement des tables avec des dizaines de milliards de lignes. Aller à la sécurité de Lokad 4.10

Ce point est particulièrement technique et dépasse le 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 basée sur le cloud de Lokad peut-elle être configurée en fonction de contraintes strictes de bande passante et de latence (côté client) ? Par exemple : bande passante = 3 Mbps (téléchargement) / 1 Mbps (téléversement), latence = 600-800 ms

Oui, l’application web conçue par Lokad a été conçue pour pouvoir prendre en charge 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 de conception technologique fondamentaux. Ces choix de conception architecturale distinguent également Lokad de la norme. Les préoccupations concernant la bande passante sont abordées de deux manières. Tout d’abord, nous sommes parcimonieux en ce qui concerne les composants tiers JavaScript. Nous avons moins de 1 Mo d’actifs à récupérer initialement. Deuxièmement, la plateforme offre un contrôle complet sur la quantité de données à inclure dans un seul tableau de bord. Ainsi, si la connectivité est faible, il est possible de rendre le tableau de bord approprié “léger”. En ce qui concerne les préoccupations de latence, nos tableaux de bord ont été conçus pour regrouper toutes les données pertinentes du tableau de bord dans une seule requête HTTP. Cela minimise les frictions subies par les utilisateurs finaux à faible latence.

2.17 Quelles sont les capacités moyennes et de pointe de débit de données de la solution par rapport à un benchmark de 1 (bas de gamme) et 5 (haut de gamme) messages par seconde ?

La plateforme Lokad n’opère pas avec des messages. De même, les interactions avec la plateforme Lokad ne se font pas par des messages. Cependant, le débit est important pour traiter rapidement de vastes ensembles de données transactionnelles. La plateforme Lokad gère, au total, plus de 1 pétaoctet de données. Nous traitons régulièrement plus de 1 téraoctet par minute pour de grands lots de calcul.

Un débit très élevé est important pour éviter les retards opérationnels lors du traitement de très grands ensembles de données (des dizaines de téraoctets) avec des calculs complexes comprenant des étapes d’apprentissage automatique et d’optimisation mathématique.

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

La plateforme Lokad n’opère pas avec des messages. La chose la plus proche serait les “fichiers plats”. Ces fichiers plats peuvent être envoyés à Lokad et récupérés depuis Lokad. La plateforme Lokad peut traiter des fichiers individuellement aussi grands que 100 Go. Cependant, ce n’est pas une pratique recommandée car c’est généralement un peu lourd (pas pour Lokad, mais plutôt pour les clients qui devront se familiariser avec des outils externes pour produire et consommer les gros fichiers).

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 scientifiques de la supply chain. Ces scientifiques de la supply chain sont le premier point de contact pour signaler des incidents. En cas d’incident, nous suggérons aux clients de téléphoner directement à leur scientifique de la supply chain - si le problème est urgent - ou d’envoyer un e-mail. Les scientifiques de la supply chain s’occupent de la gestion des incidents, y compris les escalades au sein de l’organisation de Lokad.

3.2 Proposez-vous un système de ticketing ?

Oui. Lokad utilise 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 des incidents à des outils tiers ?

Oui, dans le cadre d’un accord contractuel dédié.

Dans le contexte de l’optimisation prédictive de la supply chain, les “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 courtes périodes d’indisponibilité) comme des “incidents”. Ce sont plutôt des anomalies réelles de la supply chain - qui peuvent refléter ou non des problèmes avec les scripts Envision mis en œuvre dans le compte client - qui seraient de meilleurs candidats. Les services informatiques externes sont rarement impliqués dans la résolution de ces incidents.

3.4 Comment assurez-vous une disponibilité élevée ?

Lokad est devenu un précurseur (vers 2010) des plateformes de cloud computing précisément pour garantir une disponibilité plus élevée. En plus de rendre l’infrastructure redondante (voir Incidents 3.5), la conception de la solution de Lokad met fortement l’accent sur la simplicité. Contrairement à des solutions logicielles d’entreprise comparables, nous avons significativement moins de dépendances complexes (presque d’un ordre de grandeur). Une énorme couche 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 disponibilité élevée 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 étatiques comme le SFTP. De plus, le stockage des données n’est pas seulement redondant mais également géographiquement redondant. 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 utilisée par Lokad. La redondance intégrée de la plateforme de Lokad garantit que les défaillances matérielles transitoires n’affectent pas le temps de disponibilité pendant que la plateforme de cloud computing réalloue une nouvelle ressource non défectueuse. Pour le stockage de données persistant, Lokad n’utilise que des services (par exemple, des magasins clé-valeur) 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 récupération après sinistre graves (au-delà d’une panne au niveau du centre de données). 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é-instantiation 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 le contact avec tous nos clients, suivant généralement un processus convenu avec chacun. Pour la plupart de nos clients, les scientifiques de la supply chain désignés agissent comme points de contact principaux pendant la période de récupération.

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

La solution de Lokad présente une conception de protection continue des données grâce à la sauvegarde incrémentielle en direct de son magasin d’événements et de sa source de contenu. Par conséquent, nous pouvons effectuer une récupération à un instant donné pour n’importe quel moment donné (jusqu’au niveau de la minute).

Nous avons un RPO d’une minute pour les catastrophes au niveau du centre de données - si les données ne sont pas compromises. Nous atteignons cela en exploitant des écritures géographiquement redondantes de notre magasin clé-valeur persistant. Si le magasin clé-valeur est compromis, Lokad récupère à partir de son stockage de sauvegarde (maintenu aussi isolé que possible de nos systèmes de production), également hébergé dans un emplacement 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 a-t-elle la capacité d’ajouter ou d’étendre des vérifications 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 de Lokad n’opère pas avec une base de données transactionnelle mais avec un magasin d’événements, adoptant une conception de sourcing d’événements plutôt qu’une conception relationnelle. Cela ne supprime pas la nécessité de faire respecter l’intégrité des données, mais ces préoccupations sont traitées de manière alternative.

En ce qui concerne le traitement des données client, Envision (DSL de Lokad) dispose de capacités étendues pour 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 la manière jugée appropriée par le client.

3.11 Les sauvegardes sont-elles testées périodiquement pour garantir le bon fonctionnement de la restauration des données ?

Oui. La conception de sourcing d’événements de Lokad, combinée à son magasin d’adresses de contenu, rend les tests de sauvegarde et de restauration des données beaucoup plus simples que pour la plupart des conceptions classiques qui utilisent 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 garantir le bon fonctionnement de la reprise après sinistre ?

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

Voir Incidents 3.8.

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

Oui. Nos outils internes prennent en charge la possibilité 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 versioning étendues (par exemple, les scripts Envision sont versionnés et les versions précédentes sont accessibles depuis l’application), cette capacité est rarement utilisée.

3.14 Les plans de sauvegarde et de reprise après sinistre répondent-ils aux exigences des clients en matière d’objectif de temps de récupération (RTO), d’objectif de point de récupération (RPO) et de scénarios de sinistre (tels que définis et convenus avec les clients respectifs) ?

Oui. L’objectif de temps de récupération (RTO) se référerait ici au temps pendant lequel la plateforme de Lokad pourrait théoriquement être hors service sans causer de dommages importants au client, ainsi que le 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 beaucoup des détails spécifiques des processus pris en charge/fournis par Lokad. Par exemple, un client comptant sur Lokad pour planifier des commandes d’achat mensuelles à l’étranger peut avoir un RTO d’une semaine. En revanche, un client qui compte sur Lokad pour optimiser l’expédition quotidienne de son inventaire d’un entrepôt vers plusieurs magasins peut avoir un RTO d’une heure.

En pratique, diverses contingences techniques peuvent être mises en place pour améliorer considérablement le RTO (c’est-à-dire réduire un temps d’arrêt théorique). Par exemple, des décisions de basculement peuvent être calculées à l’avance. Ces décisions peuvent être utilisées si la plateforme Lokad n’est pas disponible. Comparées aux décisions “normales” optimisées, les décisions de basculement peuvent présenter une performance d’approvisionnement légèrement dégradée étant donné qu’elles (par définition) ne tireraient pas parti des données les plus récentes.

Pour nos comptes gérés, il incombe au Supply Chain Scientist chez Lokad de concevoir conjointement un processus - avec les équipes opérationnelles du client - qui offre un RTO élevé, mais qui garantit é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 plutôt qu’un problème informatique.

Voir aussi Incidents 3.9.

3.15 Si un défaut est non reproductible dans l’environnement de test, Lokad peut-il vérifier que le défaut s’est produit à partir des journaux et des données de support, et s’assurer que le défaut est corrigé conformément à l’accord de niveau de service (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 journaux sont plus efficaces pour résoudre des problèmes triviaux, tels que les temps d’arrêt du 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 journaux sont souvent insuffisants.

Ainsi, bien que Lokad conserve et consulte les journaux lorsque cela est approprié, nous ne nous appuyons pas sur les journaux pour résoudre les défauts ou vérifier que les défauts ont été corrigés. Au lieu de cela, nous exploitons principalement des choix de conception supérieurs pour fournir une plus grande 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 journaux ne permettrait pas.

Veuillez consulter Architecture de Lokad pour une ventilation détaillée des plusieurs choix de conception clés que nous adoptons pour éviter des classes 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 l’entreprise cliente ? Les enregistrements comprennent-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 de Lokad dispose de capacités de gestion des tâches/tickets/problèmes qui fournissent les détails énumérés.

En ce qui concerne les “résolutions”, il convient de noter que la philosophie de la supply chain quantitative de Lokad est de trouver le compromis le plus bénéfique sur le plan financier lorsqu’un problème se présente. La supply chain quantitative n’est pas, techniquement, une approche de “résolution de problèmes”, car les problèmes de supply chain ne sont pas des problèmes qui sont “résolus”, mais ils sont atténués en faisant des compromis financièrement éclairés.

En bref, Lokad possède les outils et les processus pour résoudre rapidement les “problèmes simples” (comme les temps d’arrêt du serveur) de manière simple. En ce qui concerne les problèmes de supply chain plus importants et plus conséquents (comme 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 sur 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 comprend également Envision (le DSL de Lokad), qui est utilisé pour mettre en œuvre des solutions de supply chain spécifiques au client.

4.2 Quel ensemble de développement utilisez-vous?

Les équipes d’ingénierie logicielle de Lokad utilisent Microsoft Visual Studio. Les équipes de scientifiques de la supply chain utilisent la plateforme Lokad elle-même, qui dispose de son propre ensemble de développement.

4.3 Quel système d’exploitation prenez-vous en charge?

Lokad est une plateforme basée sur le web et nous prenons en charge tous les systèmes d’exploitation qui ont 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 prenez-vous en charge?

Lokad prend en charge tous les systèmes de base de données capables de produire des exports de fichiers plats. Cela inclut pratiquement tous les systèmes de base 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 magasin de clés-valeurs. Au moment de la rédaction (janvier 2023), nous utilisons Blob Storage 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 reflètent pas les systèmes de mise en cache traditionnels principalement destinés à atténuer les problèmes de performance avec une base de données relationnelle (que Lokad n’a pas).

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

Lokad exploite Let’s Encrypt à travers des renouvellements de certificats automatisés.

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

Le principal prérequis technique est un système de transaction qui suit les stocks. De plus, il est utile que le client ait de l’expérience dans l’extraction de données (sous forme de fichiers plats) à partir de leurs systèmes transactionnels, mais ce n’est certainement pas un prérequis.

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

N/A. Lokad ne nécessite aucune licence tierce pour fonctionner. Un large éventail d’outils open-source existent pour soutenir 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 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 ou de logiciel spécial.

4.10 Quelles sont les interfaces d’entrée et de sortie 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 garantissez-vous l’absence de fuites de données entre locataires?

La solution de Lokad sépare les données des locataires par sa conception même, ce qui garantit l’absence de fuites de données (même accidentelles). De plus, tout le code expédié en production est examiné par des pairs, offrant ainsi une couche de protection supplémentaire. Enfin, nous orientons les chercheurs en sécurité (personnes effectuant des tests d’intrusion) pour enquêter spécifiquement sur 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 reflète celui de la production - afin qu’ils puissent vérifier de manière agressive cette propriété de notre plateforme.

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

Oui, mais il y a peu ou pas d’avantages à conteneuriser la plateforme de Lokad. La conteneurisation apporte de la valeur lorsqu’il y a des dépendances complexes (par exemple, une base de données transactionnelle, un système de mise en 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 classes entières de vulnérabilités. Au lieu de cela, nous maintenons la solution suffisamment simple pour que le déploiement puisse être effectué même avec de petits scripts shell.

4.13 Les composants GUI peuvent-ils être dissociés du backend?

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

4.14 L’application Lokad prend-elle en charge des fonctions de localisation (telles que le changement de langue)?

Oui, l’application prend en charge des 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à de l’ensemble 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 Les utilisateurs finaux peuvent-ils mettre à jour ou 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 étendue (en anglais). Cependant, l’utilisation de la plateforme Lokad implique la création d’interfaces utilisateur sur mesure et notre processus régulier implique au moins deux formes de documentation ou d’aide.

Tout d’abord, les tableaux de bord conçus dans la solution Lokad sont destinés à être documentés de manière contextuelle - directement à partir du tableau de bord lui-même. En particulier, nous avons même une tuile Markdown dédiée à la documentation en texte riche. Deuxièmement, nos livrables comprennent un “Manuel de procédures conjoint”. Dans l’ensemble, le manuel fournit une analyse détaillée non seulement des mécanismes de la solution, mais aussi de la raison pour laquelle chaque élément a été sélectionné (et comment il répond aux besoins spécifiques de la chaîne d’approvisionnement du client).

4.17 Le webapp de Lokad est-il réactif?

Le webapp de Lokad, ainsi que ses supports (comme la documentation technique), ont été conçus pour être réactifs. Cependant, certaines fonctionnalités avancées, comme l’édition de code, sont impraticables sur les appareils mobiles et/ou tablettes. Ainsi, la conception vise à maximiser la réactivité pour les activités anticipées réalisées sur PC et sur des appareils plus petits, respectivement.

4.18 Si votre système est un webapp, quels navigateurs et versions prenez-vous en charge? Quel est votre standard minimum pour les navigateurs internet?

Lokad est un webapp et nous prenons en charge les principaux navigateurs web “evergreen” tels que Chrome, Firefox et Safari. Nous n’essayons pas de prendre en charge les anciens navigateurs pour des raisons de sécurité, car le support de ces navigateurs met implicitement en danger notre(s) client(s). En d’autres termes, un navigateur vulnérable peut être exploité par un acteur malveillant pour exfiltrer 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 prendre en charge les capacités des navigateurs qui n’ont pas été adoptées par tous les principaux navigateurs web depuis au moins 1 an.

4.19 Pour les applications mobiles et tablettes, quels systèmes d’exploitation (et versions) Lokad prend-il en charge?

N/A. Comme Lokad est une application web proposée en tant que service, nos clients ne se préoccupent pas de la prise en charge des systèmes d’exploitation. 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 avons une grande confiance dans la portabilité étendue de la solution Lokad. Bien que nous ne ressentions aucun besoin actuel de modifier cette configuration, si des preuves valides se présentent, nous nous adapterons en conséquence.

4.20 Le webapp de Lokad peut-il fournir des notifications aux utilisateurs finaux? Si oui, quelle technologie/protocole est utilisé?

Oui, Lokad a la capacité d’envoyer des notifications via des notifications de type hook HTTP programmables. Ces hooks peuvent être utilisés pour utiliser un système tiers, fréquemment déjà en place dans l’entreprise cliente, pour 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é des données à récupérer à partir de la plateforme Lokad via SFTP ou FTPS.

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

Oui, Lokad étant une application multi-locataire, les capacités au niveau de l’infrastructure sont toutes partagées entre/à travers les locataires, c’est-à-dire les comptes clients. Cela inclut la surveillance du temps de fonctionnement, des performances et pour des raisons de sécurité, la sauvegarde, la gestion des correctifs, la mise à niveau, etc.

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

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

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

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

4.24 Y a-t-il une liste d’inventaire des actifs ou une base de données de gestion de 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 complète des actifs et sert de base de données de gestion de configuration (CMDB). Grâce à ce système, nous pouvons suivre, gérer et allouer efficacement les actifs matériels et logiciels dans toute l’organisation. Nos équipes ont la capacité d’identifier rapidement le statut, l’emplacement et la configuration de tout actif, garantissant des réponses rapides aux changements, mises à jour ou problèmes potentiels.

De plus, notre outil offre des fonctionnalités permettant une gestion détaillée du cycle de vie, garantissant que les actifs sont catalogués avec précision de l’approvisionnement à la fin de vie. Les capacités d’audit automatisées, associées à des fonctionnalités de reporting détaillées, garantissent que nous maintenons une visibilité et un contrôle complets sur notre environnement informatique, facilitant la conformité et l’allocation efficace des ressources.

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

Non, nous ne terminons pas chaque connexion à un réseau externe par un pare-feu, que ce soit Internet ou des réseaux partenaires. Notre décision est basée 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 étendre la surface d’attaque. Plus nous intégrons de composants et de systèmes, plus nous introduisons de points faibles potentiels. Les pare-feu, en raison de leur nature, fonctionnent en tant que processus à privilèges élevés. Cela signifie qu’ils deviennent des cibles principales pour les cyber-attaques, et lorsqu’ils sont compromis, les résultats peuvent être dévastateurs. Un cas illustratif est l’attaque SolarWinds, où les systèmes même destinés à protéger les informations ont été exploités, entraînant des violations significatives.

De plus, la présence de pare-feu stricts peut être contre-productive d’un point de vue 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 personnelles 4G ou 5G à partir de leurs propres appareils. De telles pratiques augmentent involontairement le risque de violations 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 informée par des préoccupations pratiques plutôt que de s’appuyer uniquement sur des mesures traditionnelles.

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

Non, Lokad n’utilise pas un environnement DMZ traditionnel au sein de notre réseau pour transmettre, traiter ou stocker des systèmes critiques et des données clients. Au lieu de cela, nous avons adopté une approche de sécurité réseau de confiance zéro.

Ce modèle ne repose pas sur des DMZ, mais fonctionne plutôt sur 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 garantit une posture de sécurité plus robuste et holistique, car elle ne dépend pas des défenses périmétriques comme 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 pensons que l’approche de confiance zéro offre une protection supérieure pour nos systèmes critiques et les données de nos clients.