Benchmark de web crawlers pour alimenter l'IA en sites web

Nous avons benchmarké quatre APIs de crawl sur trois domaines de difficulté variable à trois niveaux de profondeur maximale (5, 10, 20) avec une limite de 1 000 pages, en mesurant la couverture de crawl, le temps d’exécution, la découverte de liens, la qualité des liens markdown et la précision de l’extraction des titres.

Si vous souhaitez :

• Transformer des pages web en données structurées : consultez notre guide sur le web scraping.
• Crawler des sites web entiers, lisez la suite.

Benchmark des web crawlers

Vous pouvez consulter notre méthodologie de benchmark.

Pages crawlées moyennes vs coût pour 1 000 pages

Pages crawlées par domaine selon la profondeur maximale

Firecrawl a systématiquement crawlé environ 100 pages sur theregister.com, quelle que soit la profondeur maximale, approximativement 90 pages sur entrepreneur.com à tous les niveaux de profondeur, et seulement environ 30 pages sur amazon.com, probablement en raison de la protection agressive contre les bots d’Amazon. Il est à noter que l’augmentation de la profondeur maximale n’a eu pratiquement aucun impact sur le nombre de pages que Firecrawl a pu crawler sur aucun domaine.

Apify a démontré les performances les plus régulières, atteignant la limite maximale de crawl de 1 000 pages sur chaque domaine à chaque niveau de profondeur sans difficulté apparente, même sur des sites fortement protégés comme Amazon.

Cloudflare a présenté un comportement irrégulier lors des tests :

• Sur theregister.com à une profondeur maximale de 5, il n’a crawlé que 100 pages, mais à une profondeur maximale de 20 il a atteint près de 1 000 pages.
• Comme nous l’avons observé lors de tests précédents, Cloudflare crawle parfois une seule page puis termine complètement le travail. Nous avons confirmé qu’il ne s’agit pas d’un problème de cache (le cache était désactivé) et avons testé avec des temps d’attente entre les exécutions allant jusqu’à 1 minute, mais le comportement a persisté. À une profondeur maximale de 10 sur theregister.com, ce problème exact s’est produit : Cloudflare n’a crawlé qu’une seule page avant de s’arrêter.
• Sur entrepreneur.com, Cloudflare a crawlé 780 pages à une profondeur de 5, puis ce nombre est passé à 885 à une profondeur de 10, avant de chuter brutalement à seulement 172 pages à une profondeur de 20. Cette baisse peut être liée au fait que le planificateur de crawl de Cloudflare dépriorise ou expire les chaînes de liens plus profondes, ou elle pourrait refléter une limite de concurrence interne qui conduit le travail à se terminer prématurément lorsque la frontière de crawl devient trop grande à des profondeurs plus élevées.
• Sur amazon.com, Cloudflare a crawlé 905 pages à une profondeur de 5, mais ce nombre a régulièrement diminué à mesure que la profondeur maximale augmentait, tombant à 809 à une profondeur de 10 et à 795 à une profondeur de 20, ce qui suggère que des configurations de crawl plus profondes peuvent amener Cloudflare à consacrer davantage de temps à la découverte de liens plutôt qu’à la récupération effective des pages.

Nimble a atteint ou approché la limite de 1 000 pages sur theregister.com à tous les niveaux de profondeur (1 000 / 1 000 / 999). Sur entrepreneur.com, il a crawlé 1 000 pages à une profondeur de 5, mais a montré de légères baisses à des profondeurs plus élevées (896 à une profondeur de 10, 983 à une profondeur de 20), peut-être en raison de l’expiration du délai de 7 heures atteinte avant la fin du crawl complet à des niveaux plus profonds ; toutes les exécutions de Nimble se sont terminées par un statut de timeout. Amazon s’est avéré plus difficile :

• À une profondeur de 5, il n’a réussi à crawler que 319 pages, mais à une profondeur de 10, ce nombre est monté à 988 pages, puis a chuté à 906 à une profondeur de 20
• Cette irrégularité reflète probablement la combinaison des mécanismes de protection anti-bots d’Amazon et des contraintes de délai de Nimble, les crawls plus profonds prenant plus de temps pour traiter chaque page et pouvant rencontrer davantage de défis anti-bots en cours de route

Temps d’exécution par domaine selon la profondeur maximale

Firecrawl a été le fournisseur le plus rapide sur tous les domaines, terminant les crawls en moins de 5 minutes, généralement entre 75 et 265 secondes. Cette rapidité se fait au détriment de la couverture, car Firecrawl a également crawlé le moins de pages. Essentiellement, il termine vite parce qu’il s’arrête tôt.

Apify a mis environ 2 200 à 2 400 secondes (~40 minutes) sur theregister.com, quelle que soit la profondeur. Sur entrepreneur.com et amazon.com, les temps d’exécution ont été nettement plus longs, de 8 300 à 15 900 secondes (2 à 4 heures), reflétant des structures de sites plus vastes et plus complexes. Malgré ces temps plus longs, Apify a constamment atteint la limite de 1 000 pages, ce qui en fait le fournisseur le plus fiable en termes de rapport couverture/temps.

Cloudflare a montré des temps qui reflètent ses nombres de pages crawlées irréguliers :

• Sur theregister.com à une profondeur de 10, il a terminé en seulement 1 seconde, car il n’avait crawlé qu’une seule page avant de s’arrêter.
• Sur entrepreneur.com à une profondeur de 20, il a terminé en 10 secondes après n’avoir crawlé que 172 pages.
• Lorsque Cloudflare termine un crawl complet, les temps varient de 3 500 à 25 200 secondes.
• À mesure que la profondeur maximale augmente, Cloudflare semble privilégier l’atteinte de pages plus profondes plutôt que la couverture large, en crawlant moins de pages mais en terminant plus rapidement. Sur amazon.com, le temps d’exécution est passé de 25 200 secondes (timeout) à une profondeur de 5 à seulement 5 660 secondes à une profondeur de 20, tandis que le nombre de pages crawlées a également diminué, passant de 905 à 795. Cela suggère que le crawler de Cloudflare modifie sa stratégie à des profondeurs plus élevées, consacrant moins de temps à la découverte large et davantage au parcours en profondeur.

Nimble a atteint le délai de 7 heures (25 200 secondes) lors de chaque exécution sur tous les domaines et à tous les niveaux de profondeur. C’est notable car lors de nos tests rapides précédents avec une profondeur maximale de 1, Nimble avait terminé sans expirer. Dans le benchmark complet avec des profondeurs de 5 à 20 et une limite de 1 000 pages, il a constamment tourné jusqu’à atteindre le délai d’expiration. Malgré cela, Nimble a tout de même réussi à crawler un grand nombre de pages dans la plupart des cas (~900 à 1 000 sur theregister.com et entrepreneur.com), ce qui signifie qu’il crawle activement pendant les 7 heures mais ne signale simplement jamais la fin de l’exécution.

Taux de remplissage du texte des liens par fournisseur selon la profondeur maximale

Pour évaluer la qualité de la sortie markdown, nous avons mesuré le pourcentage de liens dans le markdown de chaque fournisseur contenant un texte d’ancrage, c’est-à-dire la partie textuelle cliquable d’un lien. Un texte d’ancrage manquant (par exemple, [](/about) au lieu de [About Us](/about)) signifie que le crawler n’a pas réussi à extraire le libellé du lien.

• Nimble : 100 % sur toutes les profondeurs
• Cloudflare : 91 à 94 %
• Firecrawl : 90 %
• Apify : 77 à 78 % , environ 1 lien sur 5 sans texte d’ancrage

La profondeur de crawl a eu un impact minime sur les taux de remplissage pour tous les fournisseurs, ce qui suggère qu’il s’agit d’une caractéristique du moteur d’analyse de chaque fournisseur plutôt que d’un paramètre de crawl.

Taux de remplissage du texte des liens par fournisseur selon le domaine

L’examen des taux de remplissage sur différents domaines révèle comment la complexité d’un site affecte la qualité de l’extraction de liens de chaque fournisseur.

• Nimble a maintenu 100 % sur tous les domaines.
• Apify a montré la plus grande variation, avec 89 % sur amazon.com mais en chutant à 66 % sur entrepreneur.com, ce qui signifie qu’un tiers de ses liens sur ce site ne comportaient pas de texte d’ancrage. Cela suggère que Apify rencontre davantage de difficultés avec les sites riches en contenu et dotés de structures de navigation complexes.
• Firecrawl a obtenu les meilleurs résultats sur theregister.com (98 %), mais a chuté à 81 % sur entrepreneur.com, suivant un schéma similaire à Apify.
• Cloudflare a été le plus régulier après Nimble, se maintenant entre 89 et 94 %, quel que soit le domaine.

Entrepreneur.com s’est avéré être le domaine le plus difficile pour l’extraction du texte des liens, Apify (66 %) et Firecrawl (81 %) y ayant obtenu leurs scores les plus bas, probablement en raison de l’utilisation intensive par le site de menus de navigation imbriqués et d’éléments de contenu dynamiques plus difficiles à convertir proprement en markdown.

Nombre total de liens dans la sortie markdown par domaine selon la profondeur maximale

La variance du nombre de liens entre les fournisseurs était constamment élevée (74 à 97 %), ce qui indique que les fournisseurs extraient des nombres très différents de liens à partir des mêmes pages. Pour obtenir une vue plus détaillée de cette disparité, nous avons mesuré le nombre total de liens markdown par fournisseur.

• Apify a renvoyé le plus grand nombre de liens au total, en particulier sur amazon.com avec plus de 420K liens à une profondeur de 5 (~423 par page). Sur entrepreneur.com, il s’est stabilisé autour de 63K, quelle que soit la profondeur. Sa sortie inclut des trackers publicitaires et des pixels de suivi à côté des liens de contenu de page.
• Cloudflare a atteint un pic à 303K sur entrepreneur.com à une profondeur de 10, mais a chuté à 53K à une profondeur de 20. Sur la même page d’accueil entrepreneur.com, Cloudflare a extrait 434 liens, contre 143 pour Apify, en capturant l’intégralité des menus et sous-menus de navigation.
• Firecrawl a constamment renvoyé de 5 à 9K liens dans toutes les configurations, limité par son faible nombre de pages.
• Nimble a renvoyé entre 3 et 40K liens au total, avec une moyenne de 5 à 28 liens par page, contre 60 à 420 pour les autres fournisseurs. Sur la page d’accueil d’entrepreneur.com, Nimble a renvoyé 13 liens, contre 434 pour Cloudflare, se limitant aux principaux titres d’articles. Son taux de remplissage de 100 % reflète le fait que tous les liens qu’il a inclus avaient un texte d’ancrage, plutôt qu’une couverture complète des liens. Nimble ne produit pas de liens markdown standard. Son décompte inclut des liens HTML échappés trouvés dans la sortie markdown.

Taux de présence du titre par fournisseur

La similarité des titres entre les fournisseurs a montré un écart inférieur à 1 % sur tous les tests et domaines, confirmant que lorsque les fournisseurs extraient un titre, ils renvoient systématiquement le même résultat. Le taux de présence du titre est également resté compris entre 98 et 100 % à tous les niveaux de profondeur maximale, ce qui montre que la profondeur de crawl n’a pas d’impact significatif sur l’extraction du titre.

Lorsque l’on ventile par domaine, certaines différences sont apparues :

Sur entrepreneur.com et theregister.com, la plupart des fournisseurs ont atteint des taux de présence du titre de 99 à 100 %. Amazon.com a été le seul domaine où des différences significatives sont apparues : Firecrawl a chuté à 93 % et Nimble à 95.9 %, tandis que Apify a maintenu 99.6 %. Cela correspond à la protection anti-bots plus lourde d’Amazon, qui peut bloquer ou altérer les réponses des pages, conduisant certains fournisseurs à renvoyer des pages sans titres extractibles.

Qu’est-ce qu’un web crawler ?

Un web crawler, parfois appelé « spider » ou « agent », est un bot qui parcourt Internet pour indexer du contenu.

Les crawlers ont dépassé le cadre des moteurs de recherche et servent désormais de couche de données agentique. Ils font office d’yeux pour les agents IA autonomes tels que Claude Code et OpenAI Operator, en contribuant à des tâches en temps réel comme la recherche concurrentielle et les transactions en plusieurs étapes.

Que fait un web crawler ?

Le web crawling a été divisé en trois modes, chacun conçu pour un objectif de crawl différent.

1. Mode découverte (traditionnel) : Les bots des moteurs de recherche comme Googlebot crawlent les URL pour les indexer, aidant les internautes à trouver des résultats via les moteurs de recherche.
2. Mode récupération (RAG) : Les bots IA comme ChatGPT-User ou PerplexityBot récupèrent des pages spécifiques en temps réel pour répondre aux prompts des utilisateurs. Ils utilisent le markdown plutôt que le HTML pour respecter les limites de tokens du modèle IA.
3. Mode agentique (orienté action) : Ce nouveau type de crawler en 2026 fait plus que simplement lire du contenu. Grâce au Model Context Protocol (MCP), ces bots peuvent interagir avec les sites web pour réserver des vols ou exécuter des commandes logicielles.

Par le passé, les crawlers utilisaient des sélecteurs tels que XPath ou CSS pour extraire des données. L’extraction native IA est devenue la norme.

Des outils tels que Firecrawl et Crawl4AI utilisent des instructions en langage naturel pour trouver des données. Au lieu d’écrire des règles pour chaque élément, les développeurs peuvent demander au crawler d’« extraire le prix du produit », et l’IA trouvera la bonne valeur même si le code du site change.

Construire ou acheter des web crawlers à l’ère de l’IA

1. Construire votre propre crawler

Idéal pour protéger la propriété intellectuelle essentielle et permettre une personnalisation poussée. Construire son propre crawler nécessite désormais de développer une couche d’agent propriétaire, et non plus simplement d’écrire des scripts Scrapy de base.

• Quand construire : Choisissez cette approche si votre crawler vous confère un avantage concurrentiel unique. Par exemple, construisez le vôtre si vous développez un moteur de recherche spécialisé ou si vous avez besoin d’un contrôle total sur des données sensibles ou réglementées.
• La boîte à outils : Vous n’avez plus besoin de partir de zéro. Les développeurs exploitent désormais le Model Context Protocol (MCP) pour permettre aux agents IA internes d’interagir avec le web.

2. Utiliser des outils de web crawling et des APIs

Les outils gérés sont passés de simples scrapers à des agents autonomes.

• Extraction zéro maintenance : Les outils modernes comme Kadoa et Firecrawl utilisent une IA auto-réparatrice. Vous spécifiez les données requises, telles que « Prix du produit », plutôt que leur emplacement dans le code. Si la mise en page du site change, l’outil s’adapte automatiquement.
• Conformité en tant que service : De nombreux fournisseurs proposent une conformité intégrée avec l’EU IA Act. Ils gèrent les journaux d’audit requis et les vérifications de retrait pour droits d’auteur, difficiles à mettre en œuvre de manière indépendante.
• Rapidité de création de valeur : L’achat d’une plateforme peut faire passer votre projet du concept à la production en quelques semaines.

Les web crawlers sont-ils légaux ?

En général, le web crawling est légal, mais selon la manière et le contenu que vous crawlez, vous pourriez rapidement vous retrouver dans une impasse juridique. Quatre grands piliers déterminent si le crawling (et le scraping qui s’ensuit généralement) est légal :

1. Public ou privé : Ne crawlez que des données ouvertement accessibles au public sans compte.

2. Informations personnelles : Évitez les données personnelles identifiables (noms, e-mails et adresses) sauf si vous disposez d’une base légale.

3. Santé du serveur : Utilisez des limites de débit pour éviter de ralentir le serveur ; évitez de « DDoSer » un site web.

4. Droit d’auteur : Les articles et images sont protégés par le droit d’auteur, mais les faits (prix, dates) ne le sont pas.

Quelle est la différence entre le web crawling et le web scraping ?

Le web scraping consiste à utiliser des web crawlers pour analyser et stocker tout le contenu d’une page web ciblée. En d’autres termes, le web scraping est un cas d’usage spécifique du web crawling visant à créer un dataset ciblé, par exemple en extrayant toutes les actualités financières pour l’analyse d’investissement et en recherchant des noms d’entreprises spécifiques.

Traditionnellement, une fois qu’un web crawler a crawlé et indexé tous les éléments de la page web, un web scraper extrayait les données de la page indexée. Cependant, de nos jours, les termes scraping et crawling sont utilisés de manière interchangeable, à la différence que le terme crawler tend davantage à désigner les crawlers des moteurs de recherche. À mesure que des entreprises autres que les moteurs de recherche ont commencé à utiliser les données web, le terme web scraper a commencé à supplanter celui de web crawler.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Quels sont les défis du web crawling ?

1. Fraîcheur de la base de données

Le contenu des sites web est mis à jour régulièrement. Les pages web dynamiques, par exemple, modifient leur contenu en fonction des activités et des comportements des visiteurs. Cela signifie que le code source du site ne reste pas le même après le crawl. Pour fournir les informations les plus à jour à l’utilisateur, le web crawler doit recrawler ces pages web plus fréquemment.

2. Pièges à crawlers

Les sites web utilisent différentes techniques, comme les pièges à crawlers, pour empêcher les web crawlers d’accéder à certaines pages web et de les crawler. Un piège à crawler, ou piège à spider, amène un web crawler à effectuer un nombre infini de requêtes et à se retrouver piégé dans un cercle vicieux de crawl. Les sites web peuvent aussi créer involontairement des pièges à crawlers. Dans tous les cas, lorsqu’un crawler rencontre un piège à crawler, il entre dans une sorte de boucle infinie qui gaspille ses ressources.

3. Bande passante réseau

Le téléchargement d’un grand nombre de pages web non pertinentes, l’utilisation d’un web crawler distribué ou le recrawl de nombreuses pages web entraînent tous une consommation élevée de la capacité réseau.

4. Pages dupliquées

Les bots web crawlers crawlent principalement tout le contenu dupliqué sur le web ; cependant, une seule version d’une page est indexée. Le contenu dupliqué rend difficile pour les bots des moteurs de recherche de déterminer quelle version du contenu dupliqué indexer et classer. Lorsque Googlebot découvre un groupe de pages web identiques dans les résultats de recherche, il en indexe et n’en sélectionne qu’une seule à afficher en réponse à la requête de recherche d’un utilisateur.

Les 3 meilleures pratiques de web crawling

1. Politesse / Taux de crawl

Les sites web définissent un taux de crawl pour limiter le nombre de requêtes effectuées par les bots web crawlers. Le taux de crawl indique combien de requêtes un web crawler peut adresser à votre site web dans un intervalle de temps donné (par exemple, 100 requêtes par heure). Il permet aux propriétaires de sites de protéger la bande passante de leurs serveurs web et de réduire la surcharge du serveur. Un web crawler doit respecter la limite de crawl du site web cible.

2. Conformité au fichier robots.txt

Un fichier robots.txt est un fichier texte placé à la racine d’un site web qui indique aux crawlers les pages auxquelles ils sont autorisés ou non à accéder. Il s’agit d’une norme volontaire, ce qui signifie que les bots conformes la respectent, mais elle n’empêche pas techniquement l’accès. Respecter le robots.txt d’un site web est considéré comme une bonne pratique et, dans de nombreuses juridictions, l’ignorer peut vous exposer à des risques juridiques ou de réputation.

3. Rotation d’IP

Les sites web utilisent différentes techniques anti-scraping comme les CAPTCHA pour gérer le trafic des crawlers et réduire les activités de web scraping. Par exemple, la prise d’empreinte du navigateur est une technique de suivi utilisée par les sites web pour recueillir des informations sur les visiteurs, telles que la durée de session ou les pages vues.

Cette méthode permet aux propriétaires de sites de détecter le « trafic non humain » et de bloquer l’adresse IP du bot. Pour éviter la détection, vous pouvez intégrer des proxies rotatifs, tels que des résidentiels proxies, dans votre web crawler.

Méthodologie du benchmark des web crawlers

Nous avons testé quatre APIs de crawl (Apify, Nimble, Cloudflare, Firecrawl) sur trois domaines de difficulté variable : amazon.com (forte protection anti-bots), entrepreneur.com (site de contenu complexe) et theregister.com (site d’actualités).

Configuration partagée

Tous les fournisseurs ont reçu des paramètres de base identiques pour garantir une comparaison équitable :

• Sitemap : désactivé, les fournisseurs doivent découvrir les pages uniquement via les liens HTML
• Liens externes : désactivés, les crawlers restent dans le domaine cible
• Sous-domaines : activés, les pages de sous-domaines sont suivies (par ex., india.entrepreneur.com)
• Rendu JavaScript : activé, tous les fournisseurs utilisent un navigateur headless
• Cache : désactivé
• Limite de pages : 1 000 pages par exécution
• Délai d’expiration : 7 heures (25 200 secondes)
• Gestion des limites de débit : attente de 20 secondes avec jusqu’à 3 nouvelles tentatives en cas de HTTP 429

Chaque fournisseur a été testé à trois niveaux de profondeur maximale (5, 10, 20) sur les trois domaines, soit un total de 36 exécutions de crawl. Les fournisseurs ont été testés séquentiellement (et non en parallèle), chaque combinaison a été exécutée une seule fois et le statut du crawl a été interrogé toutes les 1 seconde.

Apify a été configuré avec l’acteur website-content-crawler en utilisant Playwright/Firefox comme navigateur headless. L’accès aux sous-domaines était contrôlé via des modèles glob, et le proxy intégré d’Apify a été utilisé pour toutes les requêtes.

Nimble, Cloudflare et Firecrawl ont été configurés à l’aide de leurs APIs REST respectives avec les paramètres partagés décrits ci-dessus. Aucune configuration supplémentaire propre à un fournisseur n’a été appliquée au-delà des paramètres standardisés.

Pour Cloudflare, nous avons utilisé le plan Workers Paid. Le coût indiqué reflète ce que nous avons dépensé pour crawler 1 000 pages avec ce plan. Cloudflare facture en fonction du temps de rendu du navigateur plutôt que du nombre de pages.

Pour Firecrawl, nous avons utilisé le plan Hobby. Le coût indiqué correspond au montant calculé au prorata pour 1 000 crédits parmi les crédits fournis dans ce plan. Le coût effectif par page varie selon le niveau du plan et l’achat éventuel de packs de crédits supplémentaires.

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Şipi, Nazlı},
  title  = {{Benchmark de web crawlers pour alimenter l'IA en sites web}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/web-crawler}},
  note   = {AIMultiple. Consulté le 11 Août 2026}
}

Journal des modifications

9 mises à jour

Toutes9Général8Méthodologie1

1. 20267 Avr

   Suppression des sections sur les tendances du secteur, les types de crawlers et les exemples de crawl web.

2. 6 Avr

   Ajout d'un benchmark de quatre API de crawl sur trois domaines et trois niveaux de profondeur, avec graphiques de couverture, vitesse, liens et titres.

3. 6 Avr

   Ajout d'une section méthodologie détaillant la configuration de crawl sur quatre fournisseurs, trois domaines et trois niveaux de profondeur.

4. 25 Fév

   Une section, Les robots d'exploration web sont-ils légaux ?, a été ajoutée à l'article.

5. 11 Fév

   Mise à jour de la section « Qu'est-ce qu'un robot d'exploration Web ? » avec les nouvelles tendances et modes de fonctionnement.

6. 202411 Oct

   Mise à jour de l'année dans la section « Les meilleurs robots d'exploration web ».

7. 202313 Oct

   Un résumé rapide des meilleurs crawlers web de 2023 a été ajouté à l'introduction.

8. 29 Août

   Supprimé la section "Pourquoi le web crawling est-il important ?".

9. 9 Jan

   L'introduction a été enrichie d'une définition du robot d'exploration web et du web scraping.

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017.

Le travail de Cem chez AIMultiple a été cité par des publications mondiales de premier plan, notamment Business Insider, Forbes, Morning Brew et Washington Post, par des entreprises mondiales comme Deloitte et HPE, par des ONG comme World Economic Forum et par des organisations supranationales comme European Commission. [1], [2], [3], [4], [5]

Tout au long de sa carrière, Cem a été consultant en technologies, acheteur de technologies et entrepreneur technologique. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la digitalisation.

Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité du PDG. Il a également dirigé la croissance commerciale de l'entreprise de technologie profonde Hypatos, qui a atteint un revenu récurrent annuel à 7 chiffres et une valorisation à 9 chiffres, passant de 0 à ce résultat en deux ans. Le travail de Cem chez Hypatos a été couvert par des publications technologiques de premier plan comme TechCrunch et Business Insider.

Cem intervient régulièrement lors de conférences technologiques internationales. Il est diplômé de Bogazici University en tant qu'ingénieur informatique et titulaire d'un MBA de la Columbia Business School.

Voir le profil complet

Examiné techniquement par

Nazlı Şipi

Chercheuse en IA

Suivre

Nazlı est analyste de données chez AIMultiple. Elle a une expérience préalable en analyse de données dans divers secteurs, où elle a travaillé à transformer des datasets complexes en informations exploitables.

Voir le profil complet

Commentaires 1

Partagez vos idées

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire

Aggeliki

Jan 12, 2022 at 16:15

Hi Cem, I think there is a misunderstanding regarding the robots.txt role in the crawling context. The web bots can crawl any website when indexing is allowed without having the robots.txt somewhere on their top domain, subdomains and ports and so on. The role of a robots.txt is to keep control of the traffic from web bots so the website is not overloaded by requests.

Répondre