Ceci est un article invité par Oliver Frost, data scientist chez ImmoScout24, en partenariat avec Lukas Müller, AWS Solutions Architect.
En 2010, ImmoScout24 a publié un indice des prix de l'immobilier résidentiel en Allemagne : l'IMX. Il était basé sur les annonces d'ImmoScout24. Outre le prix, les annonces contiennent généralement de nombreuses informations spécifiques telles que l'année de construction, la taille du terrain ou le nombre de pièces. Ces informations nous ont permis de construire un indice de prix dit hédonique, qui tient compte des particularités d'un bien immobilier.
Lorsque nous avons publié l'IMX, notre objectif était d'en faire l'indice standard des prix de l'immobilier en Allemagne. Cependant, il a eu du mal à capter la hausse des prix du marché immobilier allemand depuis la crise financière de 2008. De plus, comme un indice boursier, c'était un chiffre abstrait qui ne peut pas être interprété directement. L'IMX était donc difficile à appréhender pour les non-spécialistes.
Chez ImmoScout24, notre mission est de faciliter les décisions complexes, et nous avons réalisé que nous avions besoin d'un nouveau concept pour y parvenir. Au lieu d'un autre indice, nous avons décidé de construire un rapport de marché que tout le monde peut facilement comprendre : le WohnBarometer. Il est basé sur nos données d'annonces et prend en compte les propriétés des objets. La principale différence avec l'IMX est que le WohnBarometer affiche les prix de location et de vente en euros par mètre carré pour des types de biens immobiliers résidentiels spécifiques au fil du temps. Les chiffres sont donc directement interprétables et permettent à nos clients de répondre à des questions telles que « Est-ce que je paie trop de loyer ? ou "Est-ce que l'appartement que je suis sur le point d'acheter est à un prix raisonnable?" » ou « Quelle ville de ma région est la plus prometteuse pour investir ? Actuellement, le WohnBarometer est rapporté pour l'Allemagne dans son ensemble, les sept plus grandes villes et les marchés locaux en alternance.
Le graphique suivant montre un exemple du WohnBarometer, avec les prix de vente pour Berlin et l'évolution par trimestre.
Cet article explique comment ImmoScout24 a utilisé Amazon Sage Maker créer le modèle du WohnBarometer afin de le rendre pertinent pour nos clients. Il traite du modèle de données sous-jacent, du réglage des hyperparamètres et de la configuration technique. Cet article montre également comment SageMaker a aidé un data scientist à compléter le WohnBarometer en 2 mois. Il a fallu 2 ans à toute une équipe pour développer la première version de l'IMX. Un tel investissement n'était pas une option pour le WohnBarometer.
À propos d'ImmoScout24
ImmoScout24 est la principale plateforme en ligne pour l'immobilier résidentiel et commercial en Allemagne. Depuis plus de 20 ans, ImmoScout24 révolutionne le marché de l'immobilier et accompagne plus de 20 millions d'utilisateurs chaque mois sur sa place de marché en ligne ou dans son application pour trouver de nouveaux logements ou locaux commerciaux. C'est pourquoi 99 % de notre clientèle cible connaissent ImmoScout24. Avec ses solutions numériques, la place de marché en ligne coordonne et rassemble avec succès propriétaires, agents immobiliers, locataires et acheteurs. ImmoScout24 travaille dans le but de numériser le processus des transactions immobilières et de faciliter ainsi les décisions complexes. Depuis 2012, ImmoScout24 est également actif sur le marché immobilier autrichien, atteignant environ 3 millions d'utilisateurs par mois.
Du sur site à AWS Data Pipeline en passant par SageMaker
Dans cette section, nous discutons de la configuration précédente et de ses défis, et pourquoi nous avons décidé d'utiliser SageMaker pour notre nouveau modèle.
La configuration précédente
Lorsque la première version de l'IMX a été publiée en 2010, le cloud était encore un mystère pour la plupart des entreprises, y compris ImmoScout24. Le domaine de l'apprentissage automatique (ML) en était à ses balbutiements et seule une poignée d'experts savaient coder un modèle (à titre d'illustration, la première version publique de Scikit-Learn remonte à février 2010). Il n'est pas surprenant que le développement de l'IMX ait pris plus de 2 ans et coûté une somme à sept chiffres.
En 2015, ImmoScout24 a commencé sa migration AWS et a reconstruit IMX sur l'infrastructure AWS. Avec les données de notre Service de stockage simple Amazon (Amazon S3) lac de données, le prétraitement des données et la formation du modèle étaient désormais effectués sur Amazon DME clusters orchestrés par Pipeline de données AWS. Alors que le premier était une application PySpark ETL, le second était plusieurs scripts Python utilisant des packages ML classiques (tels que Scikit-Learn).
Problèmes avec cette configuration
Bien que cette configuration se soit avérée assez stable, le dépannage de l'infrastructure ou l'amélioration du modèle n'a pas été facile. Un problème clé avec le modèle était sa complexité, car certains composants avaient commencé leur vie par eux-mêmes : au final, le code de détection des valeurs aberrantes était presque deux fois plus long que le code du modèle IMX de base lui-même.
Le modèle de base, en fait, n'était pas un modèle, mais des centaines : un modèle par type d'immobilier résidentiel et par région, la définition variant d'un seul quartier dans une grande ville à plusieurs villages dans des zones rurales. Nous avions, par exemple, un modèle d'appartements à vendre au centre de Berlin et un modèle de maisons à vendre dans la banlieue de Munich. Étant donné que la configuration de la formation de tous ces modèles a pris beaucoup de temps, nous avons omis le réglage des hyperparamètres, ce qui a probablement entraîné une sous-performance des modèles.
Pourquoi nous avons choisi SageMaker
Compte tenu de ces enjeux et de notre ambition d'avoir un rapport de marché avec des avantages pratiques, nous avons dû choisir entre réécrire de grandes parties du code existant ou repartir de zéro. Comme vous pouvez le déduire de cet article, nous avons opté pour ce dernier. Mais pourquoi SageMaker ?
La plupart de notre temps passé sur l'IMX a été consacré au dépannage de l'infrastructure, et non à l'amélioration du modèle. Pour le nouveau rapport de marché, nous avons voulu inverser la tendance, en nous concentrant sur les performances statistiques du modèle. Nous voulions également avoir la flexibilité de remplacer rapidement les composants individuels du modèle, comme l'optimisation des hyperparamètres. Et si un nouvel algorithme de boosting supérieur arrivait (pensez à la façon dont XGBoost est entré en scène en 2014) ? Bien sûr, nous voulons l'adopter comme l'un des premiers !
Dans SageMaker, les principaux composants du flux de travail ML classique (prétraitement, formation, réglage des hyperparamètres et inférence) sont soigneusement séparés au niveau de l'API et également au niveau de l'API. Console de gestion AWS. Les modifier individuellement n'est pas difficile.
Le nouveau modèle
Dans cette section, nous discutons des composants du nouveau modèle, y compris ses données d'entrée, son algorithme, le réglage des hyperparamètres et la configuration technique.
Des données d'entrée
Le WohnBaromètre est basé sur une fenêtre glissante de 5 ans d'annonces ImmoScout24 de biens immobiliers résidentiels situés en Allemagne. Une fois que nous avons supprimé les valeurs aberrantes et les listes frauduleuses, il nous reste environ 4 millions de listes réparties en données d'apprentissage (60 %), de validation (20 %) et de test (20 %). La relation entre les listes et les objets n'est pas nécessairement 1:1 ; sur 5 ans, il est probable que le même objet soit inséré plusieurs fois (par plusieurs personnes).
Nous utilisons 13 attributs d'annonce, tels que l'emplacement de la propriété (coordonnées WGS84), le type de bien immobilier (maison ou appartement, vente ou location), son âge (années), sa taille (mètre carré) ou son état (par exemple , neuf ou reconditionné). Étant donné que chaque annonce est généralement accompagnée de dizaines d'attributs, la question se pose : lesquels inclure dans le modèle ? D'une part, nous avons utilisé la connaissance du domaine ; par exemple, il est bien connu que l'emplacement est un facteur clé, et sur presque tous les marchés, les nouvelles propriétés sont plus chères que les existantes. D'autre part, nous nous sommes appuyés sur nos expériences avec l'IMX et des modèles similaires. Là, nous avons appris que l'inclusion de dizaines d'attributs n'améliore pas significativement le modèle.
Selon le type de bien immobilier de l'annonce, la variable cible de notre modèle est soit le loyer au mètre carré, soit le prix de vente au mètre carré (nous expliquerons plus loin pourquoi ce choix n'était pas idéal). Contrairement à l'IMX, le WohnBaromètre est donc un nombre directement interprétable et exploitable par nos clients.
Description du modèle
Lorsque vous utilisez SageMaker, vous pouvez choisir entre différentes stratégies de mise en œuvre de votre algorithme :
- Utilisez l'un des algorithmes intégrés de SageMaker. Il y en a près de 20 et ils couvrent tous les principaux types de problèmes de ML.
- Personnalisez une image Docker prédéfinie basée sur un framework ML standard (tel que Scikit-Learn ou PyTorch).
- Créez votre propre algorithme et déployez-le en tant qu'image Docker.
Pour le WohnBarometer, nous voulions une solution facile à entretenir et nous permettant de nous concentrer sur l'amélioration du modèle lui-même, et non sur l'infrastructure sous-jacente. Par conséquent, nous avons opté pour la première option : utiliser un algorithme entièrement géré avec une documentation appropriée et une assistance rapide si nécessaire. Ensuite, nous devions choisir l'algorithme lui-même. Encore une fois, la décision n'a pas été difficile : nous avons opté pour l'algorithme XGBoost car c'est l'un des algorithmes ML les plus connus pour les problèmes de type régression, et nous l'avons déjà utilisé avec succès dans plusieurs projets.
Réglage hyperparamètre
La plupart des algorithmes ML sont livrés avec une myriade de paramètres à modifier. Les algorithmes de boosting, par exemple, ont de nombreux paramètres spécifiant exactement comment les arbres sont construits : Les arbres ont-ils au maximum 20 ou 30 feuilles ? Chaque arbre est-il basé sur toutes les lignes et colonnes ou uniquement sur des échantillons ? Combien tailler les arbres ? Trouver les valeurs optimales de ces paramètres (telles que mesurées par une métrique d'évaluation de votre choix), ce que l'on appelle le réglage des hyperparamètres, est essentiel pour créer un modèle ML puissant.
Une question clé dans le réglage des hyperparamètres est de savoir quels paramètres régler et comment définir les plages de recherche. Vous vous demandez peut-être pourquoi ne pas vérifier toutes les combinaisons possibles ? Bien qu'en théorie, cela semble être une bonne idée, cela se traduirait par un énorme espace d'hyperparamètres avec beaucoup trop de points pour les évaluer tous à un prix raisonnable. C'est pourquoi les praticiens du ML sélectionnent généralement un petit nombre d'hyperparamètres connus pour avoir un fort impact sur les performances de l'algorithme choisi.
Une fois l'espace d'hyperparamètres défini, la tâche suivante consiste à y trouver la meilleure combinaison de valeurs. Les techniques suivantes sont couramment employées :
- Grille de recherche – Divisez l'espace en une grille discrète, puis évaluez tous les points de la grille avec validation croisée.
- Recherche aléatoire – Tirer au hasard des combinaisons de l'espace. Avec cette approche, vous manquerez probablement la meilleure combinaison, mais elle sert de bonne référence.
- Optimisation bayésienne – Construire un modèle probabiliste de la fonction objectif et utiliser ce modèle pour générer de nouvelles combinaisons. Le modèle est mis à jour après chaque combinaison, conduisant rapidement à de bons résultats.
Ces dernières années, grâce à une puissance de calcul bon marché, l'optimisation bayésienne est devenue la référence en matière de réglage des hyperparamètres et constitue le paramètre par défaut de SageMaker.
Configuration technique
Comme avec de nombreux autres services AWS, vous pouvez créer des tâches SageMaker sur la console, avec le Interface de ligne de commande AWS (AWS CLI) ou via le code. Nous avons choisi la troisième option, le SDK Python SageMaker pour être précis, car il permet une configuration hautement automatisée : le WohnBarometer réside dans un projet logiciel Python exécutable en ligne de commande. Par exemple, toutes les étapes du pipeline ML telles que le prétraitement ou la formation du modèle peuvent être déclenchées via des commandes Bash. Ces commandes Bash, à leur tour, sont orchestrées avec un pipeline Jenkins alimenté par AWSFargate.
Examinons les étapes et l'infrastructure sous-jacente :
- Prétraitement – Le prétraitement est effectué avec la bibliothèque Scikit-Learn intégrée dans SageMaker. Parce qu'il s'agit de joindre des blocs de données avec des millions de lignes, nous avons besoin ici d'une machine ml.m5.24xlarge, la plus grande que vous puissiez obtenir dans la famille ml.m. Alternativement, nous aurions pu utiliser plusieurs machines plus petites avec un framework distribué comme Dask, mais nous voulions le garder aussi simple que possible.
- Formation – Nous utilisons l'algorithme SageMaker XGBoost par défaut. L'entraînement se fait avec deux machines ml.m5.12xlarge. Il convient de mentionner que notre train.py contenant le code de la formation du modèle et le réglage de l'hyperparamètre a moins de 100 lignes.
- Réglage hyperparamètre – Suivant le principe du moins c'est plus, nous n'accordons que 11 hyperparamètres (par exemple, le nombre de tours de boosting et le taux d'apprentissage), ce qui nous laisse le temps de choisir soigneusement leurs plages et d'inspecter comment ils interagissent les uns avec les autres. Avec seulement quelques hyperparamètres, chaque tâche de formation s'exécute relativement rapidement ; dans notre cas, les travaux prennent entre 10 et 20 minutes. Avec un nombre maximal de 30 jobs de formation et 2 jobs simultanés, le temps total de formation est d'environ 3 heures.
- Inférence – SageMaker offre plusieurs options pour servir votre modèle. Nous utilisons des tâches de transformation par lots car nous n'avons besoin des chiffres WohnBarometer qu'une fois par trimestre. Nous n'avons pas utilisé de point de terminaison car il serait inactif la plupart du temps. Chaque travail par lots (environ 6.8 millions de lignes) est servi par une seule machine ml.m5.4xlarge en moins de 10 minutes.
Nous pouvons facilement déboguer ces étapes sur la console SageMaker. Si, par exemple, une tâche de formation prend plus de temps que prévu, nous naviguons vers la Formation page, localisez le travail de formation en question et passez en revue Amazon Cloud Watch métriques des machines sous-jacentes.
Le schéma d'architecture suivant montre l'infrastructure du WohnBarometer :
Défis et apprentissages
Au début, tout s'est bien passé : en quelques jours, nous avons mis en place le projet logiciel et entraîné une version miniature de notre modèle dans SageMaker. Nous avions de grands espoirs pour la première exécution sur l'ensemble de données complet et le réglage des hyperparamètres en place. Malheureusement, les résultats n'étaient pas satisfaisants. Nous avons eu les problèmes clés suivants :
- Les prédictions du modèle étaient trop faibles, tant pour les objets en location qu'en vente. Pour Berlin, par exemple, les prix de vente prévus pour nos objets de référence étaient environ 50 % inférieurs aux prix du marché.
- Selon le modèle, il n'y avait pas de différence de prix significative entre les bâtiments neufs et existants. La vérité est que les nouveaux bâtiments sont presque toujours beaucoup plus chers que les bâtiments existants.
- L'effet de l'emplacement sur le prix n'a pas été saisi correctement. On sait, par exemple, que les appartements à vendre à Francfort-sur-le-Main sont, en moyenne, plus chers qu'à Berlin (bien que Berlin rattrape son retard) ; notre modèle, cependant, l'a prédit dans l'autre sens.
Quel était le problème et comment l'avons-nous résolu ?
Échantillonnage des fonctionnalités
À première vue, il semble que les problèmes ne soient pas liés, mais en fait ils le sont. Par défaut, XGBoost construit chaque arbre avec un échantillon aléatoire des fonctionnalités. Disons qu'un modèle a 10 fonctionnalités F1, F2, … F10, alors l'algorithme pourrait utiliser F1, F4, et F7 pour un arbre, et F3, F4, et F8 pour un autre. Bien qu'en général ce comportement empêche efficacement le surajustement, il peut être problématique si le nombre de caractéristiques est petit et que certaines d'entre elles ont un effet important sur la variable cible. Dans ce cas, de nombreux arbres manqueront les caractéristiques cruciales.
L'échantillonnage par XGBoost de nos 13 fonctionnalités a conduit à de nombreux arbres n'incluant aucune des caractéristiques cruciales - type de bien immobilier, emplacement et bâtiments nouveaux ou existants - et a par conséquent causé ces problèmes. Heureusement, il existe un paramètre pour contrôler l'échantillonnage : colsample_bytree
(en fait, il y a deux autres paramètres pour contrôler l'échantillonnage, mais nous n'y avons pas touché). Lorsque nous avons vérifié notre code, nous avons vu que colsample_bytree
a été fixé à 0.5, une valeur que nous avons reprise de projets antérieurs. Dès que nous l'avons défini sur la valeur par défaut de 1, les problèmes précédents ont disparu.
Un modèle contre plusieurs modèles
Contrairement à l'IMX, le modèle WohnBarometer n'est vraiment qu'un seul modèle. Bien que cela minimise l'effort de maintenance, ce n'est pas idéal d'un point de vue statistique. Parce que nos données de formation contiennent à la fois des objets de vente et de location, la dispersion de la variable cible est énorme : elle va de moins de 5 euros pour certains appartements à louer à bien au-dessus de 10,000 5 euros pour des maisons à vendre dans des emplacements de première classe. Le grand défi pour le modèle est de comprendre qu'une erreur de XNUMX euros est fantastique pour les objets en vente, mais désastreuse pour les objets en location.
Avec le recul, sachant à quel point il est facile de maintenir plusieurs modèles dans SageMaker, nous aurions construit au moins deux modèles : un à louer et un à vendre des objets. Cela permettrait de saisir plus facilement les particularités des deux marchés. Par exemple, le prix des appartements non loués à vendre est généralement de 20 à 30 % plus élevé que celui des appartements loués à vendre. Par conséquent, l'encodage de ces informations sous forme de variable muette dans le modèle de vente a beaucoup de sens ; pour le modèle de location, en revanche, vous pouvez l'omettre.
Conclusion
Le WohnBarometer a-t-il atteint l'objectif d'être pertinent pour nos clients ? Si l'on prend la couverture médiatique à titre indicatif, la réponse est clairement oui : en novembre 2021, plus de 700 articles de journaux et reportages télé ou radio sur le WohnBaromètre ont été publiés. La liste comprend des journaux nationaux tels que Frankfurter Allgemeine Zeitung, Tagesspiegel et Handelsblatt, ainsi que des journaux locaux qui demandent souvent des chiffres WohnBarometer pour leur région. Comme nous calculons de toute façon les chiffres pour toutes les régions d'Allemagne, nous acceptons volontiers de telles demandes. Avec l'ancien IMX, ce niveau de granularité n'était pas possible.
Le WohnBarometer surpasse l'IMX en termes de performances statiques, en particulier en ce qui concerne les coûts : l'IMX a été généré par un cluster EMR avec 10 nœuds de tâches exécutés sur près d'une demi-journée. En revanche, toutes les étapes du WohnBarometer prennent moins de 5 heures avec des machines de taille moyenne. Cela se traduit par des économies de coûts de près de 75 %.
Grâce à SageMaker, nous avons pu mettre en production un modèle ML complexe avec un data scientist en moins de 2 mois. C'est remarquable. 10 ans plus tôt, quand ImmoScout24 construisait l'IMX, atteindre le même cap prenait plus de 2 ans et impliquait toute une équipe.
Comment pourrions-nous être aussi efficaces ? SageMaker nous a permis de nous concentrer sur le modèle plutôt que sur l'infrastructure, et SageMaker promeut une architecture de microservice facile à entretenir. Si nous étions coincés avec quelque chose, nous pourrions faire appel au support AWS. Dans le passé, lorsque l'un de nos pipelines de données IMX tombait en panne, nous passions parfois des jours à le déboguer. Depuis que nous avons commencé à publier les chiffres de WohnBarometer en avril 2021, l'infrastructure SageMaker n'a pas échoué une seule fois.
Pour en savoir plus sur le WohnBaromètre, consultez WohnBaromètre ainsi que le WohnBarometer : Angebotsmieten stiegen 2021 bundesweit wieder stärker an. Pour en savoir plus sur l'utilisation de la bibliothèque SageMaker Scikit-Learn pour le prétraitement, voir Prétraitez les données d'entrée avant de faire des prédictions à l'aide des pipelines d'inférence Amazon SageMaker et de Scikit-learn. Veuillez nous envoyer vos commentaires, soit sur le Forum AWS pour Amazon SageMaker, ou via vos contacts d'assistance AWS.
Le contenu et les opinions de cet article sont ceux de l'auteur tiers et AWS n'est pas responsable du contenu ou de l'exactitude de cet article.
À propos des auteurs
Olivier Frost a rejoint ImmoScout24 en 2017 en tant qu'analyste d'affaires. Deux ans plus tard, il devient data scientist dans une équipe dont le métier est de transformer les données d'ImmoScout24 en véritables data products. Avant de créer le modèle WohnBarometer, il a dirigé des projets SageMaker plus petits. Oliver détient plusieurs certificats AWS, dont la spécialité Machine Learning.
Lucas Muller est architecte de solutions chez AWS. Il travaille avec des clients dans les secteurs du sport, des médias et du divertissement. Il est toujours à la recherche de moyens de combiner l'habilitation technique avec l'habilitation culturelle et organisationnelle pour aider les clients à réaliser une valeur commerciale avec les technologies cloud.
- Coinsmart. Le meilleur échange Bitcoin et Crypto d'Europe.
- Platoblockchain. Intelligence métaverse Web3. Connaissance amplifiée. ACCÈS LIBRE.
- CryptoHawk. Radar Altcoins. Essai gratuit.
- Source : https://aws.amazon.com/blogs/machine-learning/predict-residential-real-estate-prices-at-immoscout24-with-amazon-sagemaker/
- "
- 000
- 100
- 11
- 20 ans
- 2021
- Qui sommes-nous
- Compte
- infection
- algorithme
- algorithmes
- Tous
- déjà
- Bien que
- Amazon
- analyste
- Une autre
- api
- appli
- Application
- une approche
- Avril
- architecture
- autour
- sur notre blog
- Automatisation
- moyen
- AWS
- devenez
- Début
- va
- référence
- avantages.
- LES MEILLEURS
- Le plus grand
- stimuler
- construire
- Développement
- construit
- intégré
- la performance des entreprises
- entreprises
- acheter
- Appelez-nous
- Peut obtenir
- causé
- certificats
- challenge
- globaux
- Villes
- Ville
- le cloud
- code
- combinaison
- комбинации
- commercial
- complexe
- calcul
- concept
- condition
- considère
- Console
- construction
- contient
- contenu
- des bactéries
- Core
- Costs
- pourriez
- crise
- crucial
- Clients
- données
- Data Scientist
- journée
- déployer
- Détection
- développer
- Développement
- DID
- différent
- numérique
- discuter
- distribué
- Docker
- Ne fait pas
- domaine
- même
- effet
- efficace
- Endpoint
- énorme
- Divertissement
- établir
- biens
- euro
- tout le monde
- peut
- exemple
- attendu
- Expériences
- de santé
- famille
- RAPIDE
- Fonctionnalités:
- Réactions
- Figure
- la traduction de documents financiers
- crise financière
- Prénom
- Flexibilité
- Focus
- Abonnement
- Framework
- Remplir
- plein
- fonction
- Général
- générer
- Allemagne
- Résumé
- objectif
- Or
- Bien
- Grille
- Réservation de groupe
- GUEST
- Invité Message
- heureux vous
- ayant
- vous aider
- ici
- Haute
- très
- détient
- Villa
- maisons
- Comment
- How To
- HTTPS
- majeur
- Des centaines
- idée
- image
- Impact
- améliorer
- comprendre
- Y compris
- Améliore
- indice
- individuel
- secteurs
- d'information
- Infrastructure
- sueñortiendo
- un investissement
- impliqué
- vous aider à faire face aux problèmes qui vous perturbent
- IT
- Emploi
- Emplois
- rejoint
- ACTIVITES
- spécialisées
- connu
- gros
- conduisant
- APPRENTISSAGE
- savant
- apprentissage
- LED
- Niveau
- Bibliothèque
- Gamme
- Liste
- inscription
- Annonces
- locales
- emplacement
- emplacements
- Location
- recherchez-
- click
- machine learning
- Les machines
- majeur
- Fabrication
- gestion
- Marché
- Rapport de marché
- marché
- Marchés
- Médias
- Métrique
- million
- des millions
- Mission
- ML
- modèle
- numériques jumeaux (digital twin models)
- mois
- (en fait, presque toutes)
- Nationales
- New Market
- Journaux
- nœuds
- numéros
- Offres Speciales
- en ligne
- marché en ligne
- Avis
- à mettre en œuvre pour gérer une entreprise rentable. Ce guide est basé sur trois décennies d'expérience
- Option
- Options
- de commander
- Autre
- propriétaires
- Partenariat
- Payer
- Personnes
- performant
- plateforme
- Point de vue
- possible
- power
- solide
- Prédictions
- prix
- Problème
- d'ouvrabilité
- processus
- Vidéo
- Produits
- Projet
- projets
- prometteur
- propriété
- public
- Édition
- Trimestre
- question
- vite.
- Radio
- biens immobiliers
- raisonnable
- relation amoureuse
- libérer
- Célèbre
- Location
- rapport
- Rapports
- responsables
- Résultats
- Avis
- Chambres
- Round
- tours
- Courir
- pour le running
- Rural
- Zones rurales
- SOLDE
- Scientifique
- Sdk
- Rechercher
- sens
- Services
- set
- mise
- significative
- similaires
- étapes
- Taille
- petit
- So
- Logiciels
- Solutions
- RÉSOUDRE
- quelque chose
- Space
- espaces
- passer
- scission
- Sports
- propagation
- carré
- Étape
- j'ai commencé
- statistique
- stock
- marché boursier
- storage
- les stratégies
- STRONG
- Avec succès
- haut
- Support
- Appareils
- Les soutiens
- surprise
- Target
- équipe
- Technique
- techniques
- Les technologies
- tester
- des tiers.
- Avec
- fiable
- ensemble
- -nous
- Formation
- Transactions
- Transformer
- tv
- comprendre
- us
- utilisé
- utilisateurs
- Plus-value
- Voir
- Quoi
- dans les
- de travail
- vos contrats
- vaut
- an
- années